Breaking in webpack when ignore node_modules about merge-options

[schnittstabil]

…because most people (like me) ignore node_modules for the transpilation process.

Mhm, why? It sounds to be an issue of your tools, or at least their configuration.

Following your reasoning, every single package–which could be useful in some non-ES6 environment–should provide an ES5 version along with its ES6 version. And if we go one step further, package maintainers should also provide ES2017, ES2018, … versions–a maintenance nightmare for developers like me, who spend their spare time to OSS 😓

Fixing your issue within merge-options seems to be the wrong place, but maybe I have overlooked something.

[manatarms]

should provide an ES5 version along with its ES6 version

This is not true. A babel preset is all you need to transpile your es6 down to es5.
Since es6 isn't fully supported by webpack uglify it removes a large part of the user base that could be using your plugin, along with the fact that node 4 does not understand es6. I'm reporting this issue because we have a million line code base and transpiling node_modules would take exponentially longer. Till now we have not had any issues because all of the plugins (About 70000 deps) we've used provide babel transpiled code. It would take a few minutes at most to set up a babel transpilation process for this code base. I would be happy to PR if that could help you.
Cheers!

[schnittstabil]

should provide an ES5 version along with its ES6 version

This is not true. A babel preset is all you need to transpile your es6 down to es5.

Maybe I have understood you wrong:

1. If I don't have to introduce a babel dependency in devDependencies
2. and thus I do not have to maintain that dependency (e.g. keep track of version bumps, etc.)
3. and I do not have to keep a dist folder in sync with the sources–especially in case of PRs etc.
4. and the git history of this projects keeps simple and the diffs keep concise

well, then, I would be happy to manage that babel preset, but only as long as babel and webpack are leading–probably only for the next 2-5 years…

Do not get me wrong, I take your issue serious. But, please try to understand: I believe, this would introduce a lot of maintenance work.

[manatarms]

I understand your concerns and they are valid. I just wanted to make sure you knew about the issue we had. I appreciate your detailed answers.
I'm closing this issue but feel free to reopen it if you'd like me to make a PR for babel.

[schnittstabil]

removes a large part of the user base that could be using your plugin, along with the fact that node 4 does not understand es6

Btw, merge-options works fine in node4 (https://travis-ci.org/schnittstabil/merge-options/builds/229371961)

I'm reporting this issue because we have a million line code base and transpiling node_modules would take exponentially longer.

A million line code base in one project? Personally, I would try to separate my concerns into distinct sub-projects. Beside the architectural benefits (e.g. benefits which come with Design by contract etc.), this probably reduces the need of transpiling the whole code base every time–just a suggestion.

As you probably use VCS to manage your code anyway, you can also fork merge-options (e.g. to your company-owned git server) and traspiling it in exactly the way you need it for your big project, see the package.json documentation for details–I cannot guess which transpiled versions my consumers really need.

[manatarms]

Sorry for the delayed response.

What I meant by a million line code base is that all our deps and dev deps together make up a million line code base. Which is why we try to improve our DX by excluding node_modules from the transpilation process. We were using this plugin in Fela, which we implement in our Cloudflare front end cf-ui code base here https://github.com/cloudflare/cf-ui.

Even though you may not know which versions are required by your consumers, the lib code should at least exclude non standard es6 features from the output. Babel is very easy to set up with next to no maintenance required.

[schnittstabil]

Which is why we try to improve our DX by excluding node_modules from the transpilation process. We were using this plugin in Fela, which we implement in our Cloudflare front end cf-ui code base here https://github.com/cloudflare/cf-ui.

Sorry, I do not know what "DX" means and I do not know which package we are talking about–is it flea (which uses ES6 Template literals) or cf-ui? If it's flea, may you share a link to its source? https://github.com/fleajs/flea does not exists. Btw, both do not (directly) depend on merge-options! 😕

Anyway, I rethought your idea and I want to note that merge-options (and its dependency is-plain-obj) already minimize the transpiling overhead, via their files package.json sections:

  "files": [
    "index.js"
  ],

---

[…], the lib code should at least exclude non standard es6 features from the output

The term "es6" refers to the Standard ECMA-262 – ECMAScript® 2015 Language Specification, which is obviously a standard; thus, I'm a bit puzzled–what ES6 features bothers you?

Babel is very easy to set up with next to no maintenance required.

If it is so easy and you still think it is worth, please create a PR, thus I could better estimate the maintenance efforts.

[manatarms]

Sorry for the confusion. DX stands for developer experience. So the longer webpack takes to create the build, the worse the developer experience.

This is the package I was referring to Fela. I believe we removed merge-options as a dependency recently. This is where we had to replace merge-options in cf-ui cloudflare/cf-ui#270.

I completely agree with you that we should be used to write modern es6 code. The main problem here is that uglifyjs-webpack-plugin is still using an older UglifyJsPlugin version. The PR is tracked here. Hopefully it'll get merged soon. Since a lot of people use webpack, your plugin has a chance of breaking on those builds.

I would be more than happy to make a PR, if you think it's worth it.

[WillsonHaw]

Just wanted to mention that I also have the same issue. I'm currently locking the version to 0.0.64 because I'm not going to add extra complexity and build time to webpack for transpiling to es5. We need es5 functionality because we need to support IE11.