Npm babel7

[brettz9]

Thanks very much for your npm commits...

I have expanded on that to update all of your deps and devDeps, including moving to Babel 7 and fixing your CLI test expectations due to the new commander help and error format...The commit messages have further detail on the rationale for the changes made...

If you can review this and #134 , I'd like to prepare a PR for an ES6 distribution (for browsers that can use ES6 modules directly) as well as add browser and module to package.json...

[whitlockjc]

I'll get on this right away. Thank you SO much for your help, you don't know what it means to me. :)

[whitlockjc]

Quick question, does @babel/env default to ES2015? I'm trying to make sure that the browser binaries are ES2015 for now, although I'm all for moving to ES6 if we feel that it's time.

[whitlockjc]

Also, did I do what you were looking for? I've removed bower support obviously, and as a result I moved to Babel from Browserify. Not being 100% up to speed on browser development these days, is this repo npm-consumable by other web-based projects?

[brettz9]

Apologies, I should have brought that up re: preset-env... It defaults to "@babel/preset-es2015, @babel/preset-es2016 and @babel/preset-es2017 together".

However, since it is not so meaningful to just target a version or versions of JavaScript independent of the browsers/environments one wishes to support, especially since some environments may support part of a spec, preset-env lets you specify the specific supporting browsers/envrionments you want to compile for (see https://babeljs.io/docs/en/babel-preset-env#browserslist-integration and https://github.com/browserslist/browserslist#full-list ). We could give a target of "cover 100%" to be fully backward compatible, though that may bloat things, especially if the source uses a lot of ES6+ features.

(This browserslist config is also reusable by other tools such as eslint-plugin-compat which informs you of compatibility issues for your targets during linting (including if you are doing linting in your IDE--I like linter-eslint for Atom).)

On a related note, I'm wondering if you are ok with moving toward more ES6 features in source, such as preferring const (or let as needed) over var.

Note, however, that if source uses async functions--which may be admittedly quite attractive especially for code such as yours--or generators, the Babel output will expect the presence of @babel/polyfill (for its use of "regenerator runtime") even on browsers/environments that support such functions. The polyfill file is also needed for ES6 globals or built-in prototype additions like String.prototype.includes.

I personally like to require the polyfill as it gives one freedom to use succinct, clear, and modern structures in source, and many projects depend on @babel/polyfill anyways, but that's of course your call.

But we can support ES6 Modules in source (and dist) without the polyfill, so I'm hoping to add that in a PR...

[brettz9]

Yes, your commits were a big help, and gave me the energy to tweak things a little bit more.

As far as modern browser-development readiness, for compilers like webpack or rollup, while I see you've included dist now, we'll also want to add a browser field to package.json so these tools will automatically know which file to bundle for browser builds.

Similarly, I'd like to add the module field to package.json to point bundlers to our ES6 distribution once I may be able to provide a PR for such modules so that users only targeting ES6-Module-supporting browsers can use such a distribution with no need for introducing globals and extra script tags.

Note that even if source is expressed as an ES6 module, one will likely want or need a separate ES6 Module distribution file, whether because of the desire to bundle the modules into a single file or because the browser won't understand the likes of import lodash from 'lodash'; as browsers require resolved paths. But again, merely supporting ES6 Modules in source and dist does not tie one to the polyfill, so there is no down-side to supporting them (except that one must run the build steps before being able to use Node since Node doesn't support ESM yet, though for non-production, one can use npx babel-node to compile ESM on the fly with Node too).

[brettz9]

Are you dead-set on using Webpack? I find Rollup much easier, and it has no problem providing an ES distribution... While I got it to work in Webpack, it only seems to build correctly with the CLI and despite using the same config, not with the Node API run by Gulp... I find Webpack very frustrating to use, and apparently others do too...

[brettz9]

Would you be open to a PR which used Rollup at least for the ES distribution portion?

[whitlockjc]

There is so much to respond to, I'll do my best.

1. I do not have a preference on which tool I use for creating browser bundles. I would be interested in a PR to use Rollup vs. Webpack but it should be a separate thing.
2. I would love to move to ES6 for the sources of this project.
3. Updating package.json to do things the browser and node way appropriately is ideal and I'm open to PRs.

When it comes to ES6 and fine tuning what I've already done to be more appropriate, I'd love to collaborate on this. And as usual, PRs are always welcome.

[whitlockjc]

I've not used npm for browser development so a number of your suggestions make sense but I wasn't aware I needed to do it. I want json-refs, and all other projects, to do things the right way when building libraries both for browser and node.

[brettz9]

Ok, thanks, that is helpful. I think the only remaining item for this particular PR, unless you have any other concerns, is determining which browserslist targets to indicate. Did you want cover 100% or did you want to define your own targets like "last 3 chrome versions" and what not?

[whitlockjc]

I did some digging and even the webpack project suggests rollup since json-refs is a library, not an app: https://medium.com/webpack/webpack-and-rollup-the-same-but-different-a41ad427058c#989e So I'm even more interested in this change now. I'll use whatever I learn from this for https://github.com/whitlockjc/path-loader and https://github.com/apigee-127/sway

[whitlockjc]

As for coverage, follow convention for similar projects I guess. I do not have an opinion. But that was one of the benefits of using ES2015, all major browsers support it.

[brettz9]

After rebasing, I'm not able to complete the default Gulp steps due to a synk "Not authorised" error.

[whitlockjc]

Yeah, switching to snyk was not ideal, we'll be migrating to npm audit. If you run the tasks manually it should be fine.

[whitlockjc]

4247303 no longer runs snyk target by default. Rebase and things should just work.

[brettz9]

I've gone ahead and rebased. I also updated npm packages (except Gulp) further, added a gulp script (to get easy access to the default via npm run gulp), simplified the test script (as per https://docs.npmjs.com/misc/scripts#path , the binaries are made available by npm on the PATH, so no need to spell out the Gulp binary path), and added an .eslintignore (allows one's IDE to avoid attempting to lint json-refs build files when viewing those files).

[brettz9]

The Travis failure appears to be due to Synk...

[whitlockjc]

I have updated TravisCI to no longer run gulp snyk, so rebasing should fix this. Sorry about that.

[brettz9]

I've rebased (and it is now passing).

[whitlockjc]

Thanks a lot @brettz9!

[whitlockjc]

@brettz9 Any chance you still plan on doing a PR to migrate from webpack to rollup?

[brettz9]

I hope to at some point, but please be aware my health is poor and I've been having a down spell these days, not able to work at all... But may be better with warmer weather...

[whitlockjc]

@brettz9 I am sorry to hear that, I hope things get better for you. If I can help in any way, let me know.

[brettz9]

Thank you

[brettz9]

I've been feeling better, so was able to submit PR #162