Parcel: It's time to talk about 'parcel.config.js'

[hyingreborn]

webpack 100 lines
parcel 0 lines
I need 10 lines

Zero configuration is an impossible desire，people like simple ，but project need configurability

[shawwn]

It would be helpful to list a few scenarios that this config file should support. Maybe we can either make it unnecessary or at least do the absolute minimum configuration.

Note that we need to put a lot of thought into this. It's important not to just ship a half-baked solution for one or two cases. Whatever we do here will affect all parcel users, and a lot of people are starting to use parcel now.

[TheLarkInn]

I thought that kind of goes against the value proposition. Or is this more to approach this in a _really sensible way_. (BTW we are challenged in the same way with this at webpack). It all boils down to the maintainibility and "surprise" level of the API.

[yeskunall]

From the tagline:

Blazing fast, zero configuration web application bundler

... and I quite like that it's _zero configuration_. That's what caught my eye in the first place.

But like @shawwn said, this needs to be discussed in great lengths before we make a decision.

[rondonjon]

Stay strong, resist the temptation.

As I understand it, parcel was meant to be different. If that works out, it is a true benefit.

There are plenty of alternativew available for edge cases.

[DeMoorJasper]

In think the only config we would need is a .parcelignore, this way we could specify packages to ignore completely or not parse. Everything else can already be configured in their own config file.

Which could contain the following:

node_modules/jQuery // Ignore this entirely
node_modules/React // Ignore this entirely
!node_modules/lodash // Parser can skip this and just bundle it as is

[devongovett]

I would like to avoid adding a parcel specific config. Once we add it, it's a slippery slope to end up like webpack. If there are specific configurations you need, please open issues for those and we will discuss them case by case, but usually configurations can be limited to ones that are specific to related tools like .babelrc, .postcssrc, etc.

[eavichay]

in the context of custom elements, babel requires a custom plugin transform-class-properties in order to work properly. But this breaks the source maps config. Can the source maps method be changed in parcel somehow? Switch from inline-source-maps to eval and vice versa?

[davidnagli]

@eavichay No, there's no way to configure source maps currently. Please open a new issue if the way source-maps work is causing any problems.

[Javiani]

I really tried to use Parcel, but that no configuration philosophy doesn't quite match reality.
The last plugin I tried to use was nunjucks plugin, but I coudn't configure it at all, like adding globals, filters, and that makes it quite useless if you can't extend it.

Documentation is also pretty poor...

I got several cases where I coudn't make a simple application to work due to its inflexible nature.

I'm really impressed to see that it has more than 22,000 likes.. It's not mature, the most available plugins are quite amateur ... It might be useful for some presentations or simple apps, but it's seems not meant to be used in most production apps...

To have a bundler with no configuration is the same as create an application using only functions with no arguments. It's a really strange way of thinking for me...

Gulp still has the most smart way of doing things...even though it's not a bundler...

[eavichay]

@Javiani I Agree partially. Zero configuration is just like using webpack with all the defaults. I think that configuration simplicity is (i.e. optional tweaks) is mandatory in a bundling tool.

If at least it would load .babelrc, .babelconfig, .loaders ... as optionals I would say it could help but in real life you need tweaks to meet developer requirements.

[AlexJWayne]

Parcel is _not_ zero config, really, if you consider the CLI options as configuration.

I currently have these scripts in my package.json to make parcel work with an electron app.

    "parcel:build": "parcel build src/renderer/index.html src/main/index.js --target electron --public-url .. --out-dir dist --cache-dir .parcel-cache",
    "parcel:watch": "parcel watch src/renderer/index.html src/main/index.js --target electron --public-url .. --out-dir dist --cache-dir .parcel-cache"

It sure would be nice if at least the CLI options could be abstracted to a .parcelrc or something.

[tunnckoCore]

@Squeegy Exactly, i'm for that too.

[gaui]

👍 for .parcelrc

[dandv]

I want Parcel to not do any transpilation, because I'm only targeting Chrome. If I do that via .babelrc, I get an error that Parcel

Failed to install babel-core

Well, that's the point, I don't want babel-core.

[devongovett]

@dandv you can use browserslist to disable transpilation. Just add ”browserslist”: [“last 1 Chrome version”] to your package.json. By adding a babelrc file, you are explicitly enabling Babel.

[dandv]

Thanks @devongovett, that worked. I'd like to extract that definition into .browserlistrc, but parcel seems to ignore that file. Same for .browserlist. Is that intended?

[n0v1]

@dandv the config file should be named either browserslist or .browserslistrc. You missed the s in browserSlist.

[AntonioRecaldeRusso]

All it takes is one cigarette.. Next thing you know, you're smoking 2 boxes per day

[mikestopcontinues]

Lest we forget shoving our config in package.json!

[GeorgeTaveras1231]

Would be nice to get parcel to work in monorepo environments. I like to use the babel option rootMode: upwards to maintain one central babel config at the root of my repository. On top of that, parcel doesn't support the babel extends option which would allow me to compose my babel configs. My current work around is to duplicate my babel configs for each project using parcel within the repo.

[rkingon]

+1 for CLI options as .parcelrc 👍

[fengzilong]

In my case, I need to use a script to figure out the publicPath from process.env.[variable] and git branch name(sounds strange I know)

Without config file, I have to use the nodejs api of parcel-bundler

const Bundler = require('parcel-bundler')
const options = {
  publicUrl: 'path_calculate_from_env_variable_and_branch_name',
}
new Bundler(entryFiles, options).bundle()

cli options is good, but any chance to leave user more choices?

honestly I wouldn't like to maintain a too long script in npm scripts

I think bundling app out-of-box with parcel-bundler is the advantage of it, but not no config file

We don't need the flexibility like webpack, but need a js file to save cli options, it doesn't violate parcel's design principle

Edit: I see a .parcelrc in parcel-bundler v2, but didn't find the cli options configuration

[rkingon]

fyi, i have since started to pretty much solely use the parcel-bundler and found it to handle just about everything that i've come across... it's really pretty simple and gives (as ops mentioned) that "10 lines of code"