-
-
Notifications
You must be signed in to change notification settings - Fork 5.8k
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
Remove jake
dependency and use NPM scripts instead
#5828
Conversation
CONTRIBUTING.md
Outdated
The Leaflet build system uses [Node](http://nodejs.org/). | ||
To set up the Leaflet build system, install [NodeJS](https://nodejs.org/en/). | ||
Note, that on Ubuntu/Debian you may need to [create a `node` symlink for nodejs package](https://stackoverflow.com/a/18130296). | ||
Then run the following commands in the project root to install dependencies: |
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.
Let's remove the Ubuntu/Debian mention and instead make sure you never need to call node
directly, only through npm run
.
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.
I do not call node
directly, but there is shebang line on the beginning of every script, that tells the system what interpreter to pass that file to (only works on Unix-like platforms, Windows just ignores that line and uses file extension to determine what executable should interpret it).
Note, that Jake also resolves node
executable that way - see Jake's CLI.
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.
As far as I understand, the line is only necessary if you call the script directly, e.g. ./script.js
from the command line, which is not the way we suggest to run the scripts (since they're part of npm
scripts). So removing the note should keep the guide clearer without consequences.
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.
Actually, it's necessary even when calling script through NPM.
For example, you may want to run a bash script through NPM - and it shouldn't be executed by node
. That's why #!/usr/bin/env node
is necessary.
There is a mention about that in NPM docs (bottom of bin
section).
More info about that shebang line.
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 only Bash script we have in the Leaflet repo is publish.sh
, and because it's Bash, it's irrelevant to the note about nodejs
executable on Debian.
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.
Bash script was just an example :)
I just wanted to clear that shebang line is necessary in order to tell NPM which executable should be used for particular script.
I added Ubuntu/Debian mention to docs only because of nodejs
/node
packages naming conflict on those platforms
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.
Hi,
Trying to get this PR going through: if I understand correctly @mourner's comments:
remove the Ubuntu/Debian mention
…and…
keep the guide clearer
…the idea would be to have a simple guide, even if we have to let some specificities (like properly linking to node in this case) to the community to figure out (there is plenty resources on how to install node). IIRC, the standard install on Ubuntu installs node
in the path, so this manual step would not be the common case. Hence we could reasonably keep it out indeed.
As for the shebang line added by @cherniavskii, it is necessary in order to have the file executed by node
without having to call node
explicitly in the CLI. However, as noted by both @mourner and @cherniavskii, since all these scripts are actually called as npm
package scripts, we can simply include the node
call in those scripts, and avoid having this shebang line cause other troubles.
E.g.:
package.json
"docs": "node ./build/docs.js"
What do you think?
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.
@ghybs I didn't know about those troubles using shebang line.
Indeed, calling node in npm scripts sounds reasonable.
the standard install on Ubuntu installs node in the path
Yes, I confirm. I have installed node on Ubuntu lately and node
alias works just fine.
I'll remove shebang lines and update docs.
Thanks!
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.
@ghybs done!
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.
@cherniavskii thank you for the refactoring! 👍
Just to be fair regarding the shebang line again, even though the above link mentions some possible issues, most npm module binaries include such a shebang line, as you noted. Therefore it is probably a very corner case…
scripts/test.js
Outdated
CLIEngine = require('eslint').CLIEngine, | ||
eslintCli = new CLIEngine(), | ||
karma = require('karma'), | ||
testConfig = {configFile : path.join(__dirname, '../spec/karma.conf.js')}; |
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.
While we're at it, could we simply get rid of this script fully? Add separate NPM scripts for ESLint and use the default Karma CLI.
Then we'd only be left with scripts for building things, so we'd leave the files in the build
directory.
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.
Good point.
This solution will have a tiny drawback - lack of custom console logs (like Checking for JS errors...
before linting source code).
Personally, I'm okay with that, since logs still would be readable enough to find out which script succeeded / failed.
But there is always an option to log this info using bash commands.
What do you think about that?
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.
I think it's enough to have various steps in separate npm
scripts — that way the relevant command will be printed before execusion so you know what's going on (e.g. > npm run lint-spec
).
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.
Done
.travis.yml
Outdated
script: | ||
- npm run lint | ||
- npm run lint-spec | ||
- npm 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.
I would put lint
and lint-spec
to pretest
script so that they're called automatically before npm test
. And it will be consistent with the current behavior where npm test
does all the necessary checks.
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.
When tests in real browsers will be added to Travis, I would like to have separate test script for each browser (for example npm test --browsers Firefox
and npm test --browsers Chrome
instead of npm test --browsers Firefox,Chrome
) to avoid mixing logs from different browsers (for better readability).
Adding lint
and lint-spec
to pretest
script will trigger linting for each test run, which makes no sense.
From the other hand, having linting scripts inpretest
would be handy for local development.
What solution do you prefer?
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.
Hi @cherniavskii,
While having lint
check on its own script to avoid duplication in Travis is nice, it is true that executing it automatically with every npm test
command during dev is much more comfortable.
Having the lint
triggered for each browser in Travis does not harm much.
If you really want to avoid the duplication, we could imagine configuring Travis to use another command that does not include the lint
phase:
package.json:
"pretest": "npm run lint && npm run lint-spec",
"test": "npm run test-nolint",
"test-nolint": "karma start ./spec/karma.conf.js"
.travis.yml:
script:
- npm test
- npm test-nolint --browsers Firefox
- etc.
What do you think?
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.
@ghybs thanks for your comment!
Having the lint triggered for each browser in Travis does not harm much.
It's true, but if it's possible to avoid this duplication - I'd like to do it :)
I really like solution you proposed! Will update PR!
What's wrong with Jake? |
@Klortho for starters, it's simply unnecessary. You can see how much code the PR removes. Also, I find simple NPM scripts easier to maintain, and they are more familiar to new contributors. |
Run linting scripts in pretest script, this way test script will automatically trigger code linting. Add test-nolint script to have possibility to run tests without triggering pretest script with linting. This is useful when running tests in different browsers and tere's no sense to lint code more than one time
@mourner I think your previous change requests have been addressed now… |
PR modified according to the requested changes
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.
Nice simplification of development dependencies!
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.
Me like. 👍
jake
dependencytest-jake
NPM script (as duplicate oftest
script)Jakefile.js
build
with NPMbuild
script