Comments (9)
…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.
from merge-options.
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!
from merge-options.
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:
- If I don't have to introduce a
babel
dependency indevDependencies
- and thus I do not have to maintain that dependency (e.g. keep track of version bumps, etc.)
- and I do not have to keep a
dist
folder in sync with the sources–especially in case of PRs etc. - 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.
from merge-options.
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.
from merge-options.
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.
from merge-options.
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.
from merge-options.
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.
from merge-options.
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.
from merge-options.
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.
from merge-options.
Related Issues (15)
- Is this different in results than lodash.merge? HOT 1
- CVE HOT 1
- [Request] Keep first param reactive like Object.assign HOT 1
- npm audit reports this package as problematic for prototype pollution HOT 6
- undefined values are merged HOT 4
- Can a stable release be published? HOT 1
- TypeScript is not supported HOT 5
- node 12 support? HOT 2
- cjs/esm support breaks IntelliSense of VSCode HOT 1
- Rollup complains
- Fails to build on create-react-app: Publish ES5 to NPM HOT 6
- [production build] Unexpected token: operator (>) [scripts/main_d82bc1a8.js:7487,44] HOT 1
- Snyk vulnerability report HOT 3
- Consideration for Alternate Array Handling HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from merge-options.