-
Notifications
You must be signed in to change notification settings - Fork 66
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
Typescript, Rollup, Jest, Terser, Rimraf, announcer, de-binarying, CI platforming #107
Closed
Closed
Changes from all commits
Commits
Show all changes
22 commits
Select commit
Hold shift + click to select a range
a4cad5c
Adds node 16; builds on win/mac/linux; removes pnpm; adds npm install…
StoneCypher 9d2a92b
Temporarily de-check 10.x
StoneCypher 6007b8f
compiling
StoneCypher a26c3d5
rollup and typescript
StoneCypher e060a31
terser
StoneCypher 7cccf9a
Also Jest, and a version incrementer
StoneCypher 9979d55
oh and coverage
StoneCypher a4c4d9a
merge prior to squash
StoneCypher b558583
post-merge
StoneCypher 5dfe18f
remove binary executable status of benchmark/run, commute to run.js
StoneCypher 211242c
re-involve peggy; complete
StoneCypher 6d79b2f
uh, does gha need the extension?
StoneCypher 3fb5e27
it ... it couldn't be a name conflict?
StoneCypher 244c3c4
removing benchmark from ci to see what happens
StoneCypher 854d823
remove vestigial test claim from action
StoneCypher b25b9df
remove coverage from repo (prs too annoying, will do in action in art…
StoneCypher 5bd8083
Add announcer; update changelog; deposit minified file
StoneCypher 7a9e97f
regress version bump (version dent?) from 1.2.0 back to 1.1.0
StoneCypher 8a67d82
Fix many linting errors. Move version script to tools/set_version.js…
StoneCypher c32aac6
last step cleanups
StoneCypher 4f49a1d
modernize chai and sinon
StoneCypher fde3ed8
missed linting after moving set_version; fixed
StoneCypher File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,5 +1,7 @@ | ||
browser/* | ||
browser/ | ||
examples/*.js | ||
node_modules/ | ||
pnpm-lock.yaml | ||
yarn.lock | ||
build/ | ||
coverage/ |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -10,5 +10,7 @@ src | |
test | ||
tools | ||
.vscode/ | ||
build/ | ||
pnpm-lock.yaml | ||
yarn.lock | ||
coverage/ |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Large diffs are not rendered by default.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,3 +1,9 @@ | ||
|
||
// This file is generated. | ||
// Do not edit it! Your work will be overwritten. | ||
// | ||
// Instead, please look at ./tools/set_version.js | ||
|
||
"use strict"; | ||
|
||
module.exports = "1.1.0"; |
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
This should probably be
npm ci
since we've gone to the trouble of not caching anything, installing all of the dev tools, and the pain of package-lock. This can be fixed later, though.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.
the reason it is traditional to not use
npm ci
in a situation like this is thatnpm ci
is a newcomer to the node world - it was only introduced in node 5.7, which is more than halfway into node's lifecycle, and long after it had continuous integration norms.npm ci
is meant to be used when the ci build is different than the local build. when a node programmer sees thatnpm install && npm run build
- the default for their own local setup - is being used to test in ci, they learn quite a bit about the expectations of strength of their local test set.(i don't actually understand how package-lock is relevant here, so maybe i'm missing something)
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.
npm ci
requires a package-lock, and I'm still salty about having to maintain what I think of as a useless file (for a package with no dependencies), but I'm willing to do it since there's some potential theoretical benefit to it. I'm looking for any real benefit to maintaining it so I stop feeling salty. :)Note: that's all about my feelings about myself, and unrelated to the technical solution we pick. It's just background.
We don't have to move to
npm ci
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.
There is a benefit. It's ridiculously niche, but it has burned me once in the real world. There is a second theoretical benefit that I've never seen personally.
The thing I've seen
Node sometimes builds non-node services. Those things are frequently built through tools like
node-gyp
. Those occasionally interact with operating system level package managers.Back in yon paleozoic era, when we still used things like
nightmare
to manage browser testing, it was reasonably common to have bothnightmare
andselenium
in place, because you could do most of your acceptance tests innightmare
with 1/10 the effort ofselenium
, but since that was electron and locked you into current-chrome
, you could also do your horror path stuff inselenium
and have full browser backversion testing.selenium
requested thecairo
(an svg renderer) version in the package manager;electron
set a floor, instead.electron
had a several years newer version thanselenium
did.We were image testing SVG. The version of
cairo
in use determined whether several things we needed, particularly miter joins on path endcaps, actually worked correctly.As a result, if you installed
electron
first, you'd get the version ofcairo
that had been modern when your chosenelectron
distro was used, whichselenium
would happily useIf on the other hand you installed
selenium
first, you'd get the old version, and then the supporting tools aroundfreetype
would cause a version lock (thinkanaconda
requirements,) meaning that when it upgraded, it'd actually get the correct modern version, instead of whatever electron thought was the modern versionWe had a significantly obsoleted electron version because one of our customers was struggling to update their SSL ciphers because they in turn had some customers running on like windows negative four or something
Therefore, depending on what order you installed the two non-node things, you'd get significantly different tooling behavior from your underlying support libraries
It took us three days to figure out what the hell was wrong. Once we did, we just installed the libraries before doing node anything, and it went away
However if you're distributing something where a user needs to rely on
node-gyp
or its demon bretheren, order of construction can be importantThe thing I haven't seen
Rumor has it an equivalent problem can exist inside of javascript node dependencies.
I've never understood how, or heard a coherent explanation, but the author of babel maintains this to be true, so I believe it.
I have never seen it and cannot explain.
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.
wrt
npm ci
, i'm probably actually going to move to it later, to give you the variant behavior you want for eslintthat's an appropriate time because at that point ci really is behaving differently than local
i was just explaining why i hadn't yet done that