N.B. can't run typings.typings and typings.msgTypings in parallel
yet because the latter depends on the existence of an output directory
created by the former.
* Modify scripts/gulpfiles/typings.js to write typings to BUILD_DIR.
* Modify tests/scripts/compile_typings.sh to check compilability of
resulting output from BUILD_DIR.
* Rename checkin script to checkin:built, add a checkin:typings script
to do the same for .d.ts files, and a new checkin script to do both.
* Have recompile run checkin:typings.
- Do not run npm install.
- Do not re-run build that has already been run by a previous test.
- Check files in built/ instead repo root.
- Fix formatting, styleguide issues.
The documented release process is to do npm run recompile, merge the
resulting branch to develop, and then do npm run relase, which does
not do another build.
This process should probably be changed, but for the moment ensure
that npm run recompile (as well as npm run package:beta) runs
buildTasks.checkinBuilt after each .build to preserve the old procedure.
You can now do npm run clean:buildDir, ... clean:releaseDir, or just
... clean, which does both.
The release directory is automatically cleaned before packaging
commences.
There are some files in msg/json/ (currently en.json, qqq.json,
constants.json and synonyms.json) that are generated by
scripts/i18n/js_to_json.py as part of the language file build process
- but this only needs to be done when messages.js is updated and
and usually requires some manual cleanup, so remove this step from the
existing buildLangfiles gulp script and create a separate command
('npm run generate:langfiles') to do this when required.
I have verified that
npm run build && npm run package
produces an identical dist/ directory compared to the one produced prior
to this and the previous commit.
Make the destination directories for certain build/package/release
steps more easily (and centrally) configurable.
This only deals with building *_compressed* files;
blockly_uncompressed.js and the various msg/js/*.js files are not
affected by this commit.
These functions have side effects and set all kinds of private fields. It is misleading for them to return the top-level element, for the caller to assign to a private field.
Fixes#2338.
I also looked at having workspace.clear delete any insertion marker, but there doesn’t appear to be a public API for this. Shouldn’t matter, this should be sufficient.
* Now throws error for getField/getFieldValue/setFieldValue if provided name is not a string
* Changed error to more specific TypeError
* Type checking and error message moved up to getField
* Tests added/modified to check that non-string types for field names produce type errors
* Added tests for getting/setting field (values) when names are not supplied and test for getting a field value, setting it to a new value, and getting it again.
* Added more user-friendly error message for setFieldValue telling the developer that he/she is missing the name rather than Field "undefined" not found.
* Fixed lint error by removing trailing space
* Added tests for getting/setting field (values) when names are not supplied and test for getting a field value, setting it to a new value, and getting it again.
* Added more user-friendly error message for setFieldValue telling the developer that he/she is missing the name rather than Field "undefined" not found.
