Support optionally bundling node_modules for --target=node

[devongovett]

Closes #796.

This is an updated version of #796.

• Adds a --bundle-node-modules flag, which turns on bundling of node_modules for --target=node and --target=electron.
• Disables browser field resolving for non --target=browser
• Disables bundling node builtin modules (e.g. fs, zlib, etc.) for --target=node.

[vladbat00]

Hi! Thanks for the really nice feature. It would also be very cool to specify which modules to bundle and which ones not. In my project I want to bundle only several packages (my internal libs), but not all the packages.

[lpil]

@mvlabat Sounds useful, but could we make that a later enhancement?

It'd be nice to avoid adding additional features in this PR so that it can go through more quickly :)

[mohsen1]

How does this work for modules that compile binaries per platform using Gyp? If I bundle on Linux, is there a chance that program will not run in MacOS?

[devongovett]

we don't handle native node modules yet. that would be a separate feature.

[taschmidt]

This is great! Any idea when 0.10.0 will be pushed?

[GuiRitter]

I like this, apparently solves a problem I'm trying to fix. I said "apparently" because another problem showed up, and maybe Parcel can be improved to fix it.

I'm trying to bundle text-to-svg as a dependency. That package comes with a fonts/ipag.ttf file that I suspect is not bundled. I'm trying to find a workaround to get this font loaded.

Any chance Parcel can be improved to bundle resources as well?

Edit: finished the workaround. I just copied the font to a fonts folder I had in the same folder as the bundle, edited the bundle and changed '../fonts/ipag.ttf' to './fonts/ipag.ttf'.

[purkhusid]

Any timeline on when a release with this feature will be published?

[tripodsan]

@devongovett is it possible to control which modules to bundle? e.g. when creating an package to run inside a node8 docker container, I only want to bundle the ones the container doesn't provide.

[Stradivario]

@tripodsan i think this is not a good practice try with caching your package.json file you will be really happy.The way that parcel is using packages is the way that you depend them inside your project.So basically this is not a problem with Parcel JS, rather your implementation bug. :)

The process is clear

You have an app

1. Build index.ts or js
2. If there are any packages that depends and you 'require' or 'import' they will be inside bundle accept node_modules which i hope this issue will add also.
   3.Run your app independently

There is nothing to do with Docker or any other tool to containerize your application.
Following solution will help you to cache all dependencies inside package.json then when you run your application build it will always get CACHED layer instead of installing dependencies again.If you change your package.json file then the container will be rebuilded and npm install will trigger.That way you don't need anything other inside Dockerfile and to miss configurations for building application inside Docker and Locally.Think about that try to run your application inside docker the same as inside your local environment! That way when you have complex project you will not think what is happening with the build and why it is not working! Regards! :)

Dockerfile

FROM node:8.9.4 as node
WORKDIR /app
COPY package.json .
RUN npm install
COPY ./ .

RUN npm run BUILD YOUR APPLICATION TASK

FROM nginx:1.13

COPY --from=node /app/dist/ /usr/share/nginx/html
COPY ./nginx-custom.conf /etc/nginx/conf.d/default.conf

here is your nginx default.conf

server {
  listen 80;
  proxy_buffering  off;
  location / {
    root /usr/share/nginx/html;
    index index.html index.htm;
    try_files $uri $uri/ /index.html =404;
  }
}

docker-compose.yml

version: '2'
services:

  client:
    image: yourcointaner/client:latest
    container_name: your-container-client
    restart: always
    ports:
    - 80:80

Build:

docker build -t yourcointaner/client:latest .

Start

docker-compose up

Don't forget to add node_modules inside .dockerignore

.dockerignore

./node_modules

[tripodsan]

Hi @Stradivario. thank you very much for your explanation. unfortunately, I don't want to build an entire dockercontainer; just reusing one.

here's an example:

let's say, I build an openwhisk action, using the default node 6 container.
For example, they already include lodash. So, in my javasccript, when I require lodash, I don't need to inline it.

in webpack, I could easily configure this and declare lodash as external.

[pontusab]

When will this be released?

[peanutbother]

let's say, I build an openwhisk action, using the default node 6 container.
For example, they already include lodash. So, in my javasccript, when I require lodash, I don't need to inline it.

@tripodsan you could alias these modules to a local stub pointing to your container module to do that theoretically. saying theoretically since I did not test such a scenario, but had local stubs in aliases (package.json) for having client and server common config using config module and a local stub.

You can find out about aliases here

[tripodsan]

cool. thanks for the hint, @peanutbother

[devongovett]

@tripodsan seems like you want #144

[devongovett]

@pontusab @purkhusid just published a beta that includes this feature: v1.10.0-beta.0. Please test it out and let me know if you find issues. :)

[tony-g]

How difficult/possible would it be to extend this to integrate with yarn workspaces?

e.g. in developing an electron app with workspaces, I'd like parcel to watch for changes to workspace packages like shared-module-one, but not fs etc

├── package.json
└── packages
    ├── electron-app
    │   ├── index.js
    │   └── package.json
    ├── shared-module-one
    │   ├── index.js
    │   └── package.json
    ├── etc

/* electron-app/index.js */
const fs = require('fs')
const sharedModuleFromWorkspace = require('shared-module-one')

/* shared-module-one/index.js */
// parcel won't auto-rebuild changes here when target=electron
// but would be nice if it did!