-
-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sync with Node.js master #44
Conversation
Oh also @BridgeAR, is it ok to run the Node.js tests in this way? Serially requiring each test file in the same process? Or does each test file expect to be run in it's own isolated Node.js process? Also, what are those |
b6bab61
to
183ec0a
Compare
183ec0a
to
180e659
Compare
Woop woop, tests are passing against Node.js v12.0.0-rc.1 on Travis 🎉 https://travis-ci.org/browserify/commonjs-assert/jobs/520670587 I'm guessing Node.js v11 is failing because the tests are testing functionality in master (and v12) that isn't in Node.js v11 core Hopefully these tests should start passing as I port |
5e2445a
to
00dc6d5
Compare
I've given it a try in my package with karma+karma-webpack (+ts-loader), and found its dependency "buffer" is incompatible with This is, I think, a problem in node-libs-browser (webpack/node-libs-browser#68 issued in 2017!), but until the issue is fixed, (edited) Here are my karma settings that use this branch: msgpack/msgpack-javascript#20 |
We can probably actually remove the |
Literally just pulled the Lines 5 to 37 in 8386769
All unit tests are still passing. |
@gfx just seen your edit
Just to clarify, are you saying your code doesn't work with the current published |
Yes! So I am waiting for the PR is merged! |
@goto-bus-stop @BridgeAR any ETA for publishing this? Are you just holding off merging so you can do some SemVer minor releases first or do you need something else from me? |
it's unlikely i'll be able to take a close look at this very soon, so i'm happy to go with your and @BridgeAR's judgement |
I'm happy with it and we've got a user report saying it's fixing issues for them so I'd say it's all good. I don't have npm permissions though so can't publish myself. |
"homepage": "https://github.com/browserify/commonjs-assert", | ||
"repository": "browserify/commonjs-assert", | ||
"scripts": { | ||
"build": "babel assert.js test.js --out-dir build && babel internal --out-dir build/internal && babel test --out-dir build/test", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a task to prepare npm publish
? If so, you should use the prepare
task:
https://docs.npmjs.com/misc/scripts#prepublish-and-prepare
So I can use this library by npm install browserify/commonjs-assert
even in IE11, whereas other modern browsers does not require ES5 artifacts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added, thanks.
@lukechilds added you |
Thanks! Ok unless I hear anything else from you @goto-bus-stop @BridgeAR I'll merge and do a new release tomorrow. 🎉 |
We'll handle a new release commit after this PR is merged.
YYYYYYYYYYYYEEEEEEEEEEEEESSSSSSSSSSSS!!!!!!!!!!!!!!!!! |
Just published |
Resolves #32
Obviously not ready to merge yet, just opening this PR now to have a central place for review and discussion regarding these changes.Ready to rock and roll!Just to explain my thought process:
The initial commit in this branch is nuking all existing work and the second commit is setting up the project in the way discussed in the related issue. Two main reasons for this:
I thought it would be messy to have essentially two code bases co-existing in the same branch while we're working on this. I thought it would just add confusion and add a load of noise to commits.
If we decide at some point that actually this should be a new project in a separate repo, we can just push this branch to master in the new repo and delete all history before my first nuke commit. That would give us a completely clean repo with proper history.
I've included
assert
and all tests directly from current Node.js master, including a comment header of the commit hash it references in the Node.js repo.I've also added a simple tape wrapper around the Node.js tests and these are running on Travis.
My general plan is:
assert
/util
modules without relying on internal Node.js functionality.assert
and fixing that to pass tests without relying on internal Node.js functionality.assert
is passing tests, switch over to testing against browserifyutil
rather than Node.jsutil
and fixing that to pass tests without relying on internal Node.js functionality.util
is used in both tests andassert
so it might not be possible to split the work up into clean atomic steps as described here but that's my general idea.The diff is going to be pretty noisy due to the substantial changes to the project structure so if you want to get a quick overview just have a look at the tip of the branch: https://github.com/browserify/commonjs-assert/tree/sync-with-node-master
I'm just fleshing everything out in this branch for now. However, it'll probably make sense to switch to feature branches that get merged into this branch to track changes more easily and allow other people to contribute.
Does this project structure make sense? Does my plan make sense? Any suggestions?
// cc @goto-bus-stop @BridgeAR