What tasks should be supported from within the release zip?

[hpinkos]

Reported on the forum: https://groups.google.com/forum/?hl=en#!topic/cesium-dev/eaY-tlnabK0

Running npm run build from the release fails because .jshintrc is missing from the root, apps, and apps/sandcastle directories

[mramato]

You aren't supposed to be able to run npm run build from the release zip. The release zips are only meant for using Cesium, not building it.

[hpinkos]

Then why do we include the gulpfile?

[mramato]

It was probably just an oversight from when we switched to gulp, however, having the gulpfile should let you run the tests from the command line (which is something we currently support in the released zips). Though I haven't tried it as we are still using the old Jasmine testing for release testing.

[hpinkos]

Discussion from #6025 (deleting gulp file from release)

I'm not sure this really fixes the issue because there will still be gulp-based tasks listed in package.json, so it's not going to stop our users from attempting to run build tasks against the release zip and submitting github issues or forum posts because they think it's broken. We could modify the package.json during zip creation so that it only include support commands.

But the real question we need to answer is, "What else are do we support doing with the release zip?":

1. Should you be able to rebuild Cesium (and Apps and documentation)?
   • sure, if it's easy enough
2. Should you be able to run all tests?
   • yes
3. Should you be able to run jsHint/eslint and other build stuff?
   • sure, if it's easy enough

Depending on the answers to these questions (and maybe others I glanced over) we can modify the zip further to better suit the needs.

[ggetz]

We removed the gulpfile in #10281, but after seeing #6025, I think that was the wrong move.

The reason we removed it was that it was no longer possible to run any gulp tasks from within the release zip. However, this was due to #8659 and can be fixed by including .gulp.json.

Once that file is restored, it's possible to run a subset of the tasks from within the release zip:

🔴 build and build-watch - fails with Error: ENOENT: no such file or directory, open 'Apps/Sandcastle/.jshintrc'
⚠️ build-ts - Can run if Tools/jsdoc/** is included in the releaseZip (~85KB uncompressed)
🔴 buildApps - fails to an implicit dependency on the build task
✅ clean
✅ cloc
🔴 combine and combineRelease - fails due to dependency on build
⚠️ generateDocumentation and generateDocumentation-watch- Can run if Tools/jsdoc/** is included in the releaseZip (~85KB uncompressed)
✅ coverage
✅ test-*
🔴 release and makeZipFile - fails due to dependency on build
🔴 minify and minifyRelease - fails due to dependency on build
⚠️ eslint - fails, but can pass if we include .eslintrc.json,.eslintignore, related eslint config files in the release zip (~7KB uncompressed)
⚠️ prettierand prettier-check - Passes if .prettierignore is included in the release zip (<1KB uncompressed)

Since its only possible and helpful to run a subset of these tasks, I think it make sense to modify the packaged package.json file to limit the included scripts. From conversation above and from looking at other packages, it sounds like we generally want to exclude build and dev-centric tasks, while supporting verification tasks. I would propose the following list of tasks to be included in package.json and the rest to be omitted:

• start
• start-public
• clean
• cloc
• coverage
• eslint
• build-specs
• test-*
• prettier-check

This list is arrived at by omitting build and watch tasks, as well as the deploy-* tasks. Including generateDocumentation and build-ts is arguable since they can be run to verify the validity of the docs. But we already included the generated output, and the size of the documentation build tools are not as negotiable as eslint or prettier.