Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions .gitignore
Original file line number Diff line number Diff line change
Expand Up @@ -36,3 +36,8 @@ node_modules

# Optional REPL history
.node_repl_history

# Only apps should have lockfiles
npm-shrinkwrap.json
package-lock.json
yarn.lock
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It can be useful for a library to have a lockfile checked in (and not published) so that build and test dependencies are locked to known-good versions.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don’t agree; that allows the package to pass tests while consumers fail them. Dev-only lockfiles are only appropriate for apps, not for packages.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mainly mention because I feel like I've had build and test specific dev-dependencies (such as babel-plugin-add-module-exports today :P ) break much more often than regular dependencies. It's a very painful experience to clone an old repository to make a quick tweak and find it can't even build. I find it important to guarantee that a project is in a buildable (and hopefully even fully-reproducible) state as it was in the last commit. Finding out about breakages in non-dev-dependencies is important, but omitting a lockfile so the next repo-cloner runs into it isn't the specific way I like to go about it for my own projects. (Personally, I like using greenkeeper for that sort of thing.)

I'm happy with whichever way this project goes, just wanted to dump some of my experiences and reasoning here! The main meat of this PR seems really needed and I definitely wouldn't want to delay that.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed you should use something like greenkeeper to keep up with that, rather than letting a project bitrot until you try to maintain it later.

1 change: 1 addition & 0 deletions .npmrc
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
package-lock=false
6 changes: 5 additions & 1 deletion package.json
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,9 @@
"start": "mocha --require babel-register --watch",
"test": "mocha --require babel-register",
"lint": "eslint src test",
"prebuild": "rimraf lib",
"build": "babel src --out-dir lib --source-maps",
"prepublish": "safe-publish-latest && npm run build",
"postversion": "git push --follow-tags && conventional-github-releaser -p angular"
},
"devDependencies": {
Expand Down Expand Up @@ -38,7 +40,9 @@
"eslint-plugin-standard": "^3.1.0",
"mocha": "^5.2.0",
"power-assert": "^1.6.0",
"prettier": "^1.13.7"
"prettier": "^1.13.7",
"rimraf": "^2.6.2",
"safe-publish-latest": "^1.1.2"
},
"optionalDependencies": {
"chokidar": "^2.0.4"
Expand Down
Loading