Parcel 2: multi entry/target builds

Split out of #2574.

For SSR, it would be useful to support multiple targets with different entries simultaneously.

Three options came up in the previous issue:

Explicit entries per target

const parcel = new Parcel({
  entries: {
    browserEntry_page1: '/path/to/browser/entry/of/page1.js',
    browserEntry_page2: '/path/to/browser/entry/of/page2.js',
    serverEntry: '/path/to/server.js',
  },

  targets: {
    browserEntry_page1: {
      "browsers": ["> 1%", "not dead"]
    },
    browserEntry_page2: {
      "browsers": ["> 1%", "not dead"]
    },
    serverEntry: {
      "node": ["^8.0.0"]
    },
  }
});

An array of parcel options

const parcel = new Parcel([
  {
    entries: ['page1.js', 'page2.js']
    targets: {
      browser: {
        browser: ['>1%', 'not dead']
      }
    }
  },
  {
    entries: ['server.js']
    targets: {
      node: {
        node: ['^8.0.0']
      }
    }
  }
});

Multiple Parcel instances, sharing a worker farm

We were thinking of making the worker farm an option anyway, so this might work for free. By sharing a worker farm instance, multiple Parcel instances could run in parallel.

const workerFarm = new WorkerFarm();

const browserParcel = new Parcel({
  workerFarm,
  entries: ['page1.js', 'page2.js']
  targets: {
    browser: {
      browser: ['>1%', 'not dead']
    }
  }
});

const serverParcel = new Parcel({
  workerFarm,
  entries: ['server.js']
  targets: {
    node: {
      node: ['^8.0.0']
    }
  }
});

Thoughts?

cc. @brillout @padmaia @wbinnssmith

[devongovett]

It is all possible to override, I’m just not sure we should encourage it:

{
  "main": "dist/index.html",
  "targets": {
    "main": {
      "context": "browser",
      "isLibrary": false,
      "includeNodeModules": true,
      "engines": {
        "browsers": ["> 1%"]
      }
    }
  }
}

[Banou26]

@brillout I’m sorry but that’s a big no for me, this is just unnecessarily complex,

const parcel = new Parcel({
  entries: [
    {
      entry: '/path/to/page1.js',
      target: ['browser', 'node'],
    },
    {
      entry: '/path/to/page2.js',
      target: ['browser', 'node'],
    },
    {
      entry: '/path/to/server.js',
      target: 'node',
    },
  ],

  targets: {
    browser: {
      browsers: ["> 0.25%", "not dead"],
    },
    node: {
      nodejs: "^8.0.0",
    }
  }
})

Would serve the same purpose, while being more explicit and straightforward.

I don’t like the fact that you can reference targets, from targets, this makes you have to look back everytime you see a definition that use a reference. Configurations should be explicit and simple, sure, if you have a lot of different needs, it’ll get complex, but for a simple configuration like this, it shouldn’t be and look complex for nothing.

Edit 1: BTW, about your isomorphic target, if parcel supports ESM outputs and the top level await proposal(which is getting shipped in v8 and webpack as an experiment), we could have multi-target bundles since node will, at its next version, support ESM modules as a stable feature

Edit 2: While we’re at it, we could even remove some config duplication by allowing entries as array, but then i’m not sure that entries/entry/target should be the name of the properties

const parcel = new Parcel({
  entries: [
    {
      entry: ['/path/to/page1.js', '/path/to/page2.js'],
      target: ['browser', 'node'],
    },
    {
      entry: '/path/to/server.js',
      target: 'node',
    },
  ],

  targets: {
    browser: {
      browsers: ["> 0.25%", "not dead"],
    },
    node: {
      nodejs: "^8.0.0",
    }
  }
})