3 ms·
I gave up on trying to use the babel 6 cli and wrote a global-happy replacement[1]. It still doesn't do anything by default (well, other than indent, add semi-
by ksherlock 11y ago
I gave up on trying to use the babel 6 cli and wrote a global-happy replacement[1]. It still doesn't do anything by default (well, other than indent, add semi-colons, and check syntax) but typing `babel --es2015` is easier than installing a few hundred megabytes of node modules and configuring a .babelrc file just so it can convert `const` to `var`.
1: https://github.com/ksherlock/better-babel-cli https://github.com/ksherlock/better-babel-cli
1.1: https://www.npmjs.com/package/better-babel-cli https://www.npmjs.com/package/better-babel-cli
- lobster_johnson 11y agoIndeed, I am concerned about the trend towards locally installed NPM modules, away from globally installed ones. The other project exhibiting this trend is ESLint. It used to work beautifully globally installed, then the developers broke it; it's better now, but there are still some bugs. Having one ESLint config per project and making it a direct dependency is ridiculous when you have a dozen projects and all you want is in-editor linting (in Atom, in my case).
- kevinsimper 11y agoThe problem is that you can't require global modules, so that global module needs to have installed everything that needs, and if it needs to support multiple projects with different requirements, that global modules needs a whole lot of modules itself in its package.json, and now that global module is unmaintainable, because of all its dependencies. That is why global modules is generally not useful and that it is better to have them installed locally.