Releases: ciacob/MASCOT
Support for Defining an `asconfig.json` Base
MASCOT now allows you to specify a base (or "blueprint") for all generated *.asconfig.json files.
This allows you to include persistent settings in-there, such as AIR packaging options (e.g., airOptions) or specialized compiler flags (e.g., advanced-telemetry). This kind of settings would be overwritten if you were to add them directly into each generated *.asconfig.json file, not to mention all the effort.
Please refer to the Asconfig Base section in the documentation for more details.
Known limitations in v.1.0.5
- No parallel compilation available. While Visual Studio Code's build tasks system does permit unrelated tasks to run in parallel, MASCOT does not leverage this, and always generates build tasks that are executed sequentially, even if they are unrelated. This also wastes time.
- The
src,binandlibfolder names are assumed by MASCOT and cannot be changed. If an ActionScript project uses, e.g.,projsrcfor its source folder name, that will not be recognized by MASCOT as a valid project, and will be ignored. - MASCOT does not currently recognizes couplings defined in MXML classes via custom MXML tags (by contrast, couplings defined in
fx:Scriptsections are accounted for). - MASCOT cannot detect couplings to classes that live in the
globalpackage, or live in another project but in the same package as the current class. Theg_manual_dependenciesargument/configuration directive can be used as a workaround, to manually couple such classes.
Fixing Crash on Stray Descriptor XML Files
FIXED: Stray descriptor XML files could cause MASCOT to error early, preventing the generation of any*.asconfig files.
This release addresses a bug that would surface when the workspace contains at least one Flex AIR project with a stray XML Application Descriptor — an application descriptor file pointing to a non-existing main class, such as MyMissingClass-app.xml. In this scenario, MASCOT would crash, and no files would be generated for any project. This issue has now been resolved.
This release is essentially v1.0.3 with only a bugfix. Please refer to versions v1.0.3 and v1.0.2 for additional details that remain applicable to this release.
npm -g Install fix
This fixes installation via npm install -g
This is essentially version 1.0.2 with fixes that enable it to be installed globally from npm, via:
npm install -g mascot-appPlease refer to release 1.0.2 for the rest of the details.
Selective Building
This release introduces Selective Building, an optimization that detects and skips unchanged dependencies during the build process.
Starting with v1.0.2, MASCOT will only generate build tasks for changed code, thus significantly reducing the compilation time needed for ActionScript projects with a large number of dependencies. This is now the default behavior, and can be bypassed via the newly introduced argument --g_rebuild.
Please find the 1.4. Selective Building section in README.md, which covers the topic in detail.
Known limitations in v.1.0.2
- No parallel compilation available. While Visual Studio Code's build tasks system does permit unrelated tasks to run in parallel, MASCOT does not leverage this, and always generates build tasks that are executed sequentially, even if they are unrelated. This also wastes time.
- The
src,binandlibfolder names are assumed by MASCOT and cannot be changed. If an ActionScript project uses, e.g.,projsrcfor its source folder name, that will not be recognized by MASCOT as a valid project, and will be ignored. - MASCOT does not currently recognizes couplings defined in MXML classes via custom MXML tags (by contrast, couplings defined in
fx:Scriptsections are accounted for). - MASCOT cannot detect couplings to classes that live in the
globalpackage, or live in another project but in the same package as the current class. Theg_manual_dependenciesargument/configuration directive can be used as a workaround, to manually couple such classes. - There is no way to account for manual directives in the generated
asconfig.json. MASCOT automatically generates oneasconfig.jsonfile per project, but if you want to add your own settings in-there, currently there is no way to preserve them.
1.0.1
First public release of MASCOT.
Known limitations in v.1.0.0
- MASCOT makes no differentiation between dirty and clean projects, and compiles the entire dependencies tree every time, which wastes time.
- No parallel compilation available. While Visual Studio Code's build tasks system does permit unrelated tasks to run in parallel, MASCOT does not leverage this, and always generates build tasks that are executed sequentially, even if they are unrelated. This also wastes time.
- The
src,binandlibfolder names are assumed by MASCOT and cannot be changed. If an ActionScript project uses, e.g.,projsrcfor its source folder name, that will not be recognized by MASCOT as a valid project, and will be ignored. - MASCOT does not currently recognizes couplings defined in MXML classes via custom MXML tags (by contrast, couplings defined in
fx:Scriptsections are accounted for). - MASCOT cannot detect couplings to classes that live in the
globalpackage, or live in another project but in the same package as the current class. Theg_manual_dependenciesargument/configuration directive can be used as a workaround, to manually couple such classes. - There is no way to account for manual directives in the generated
asconfig.json. MASCOT automatically generates oneasconfig.jsonfile per project, but if you want to add your own settings in-there, currently there is no way to preserve them.