Skip to content
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

Various modernisation of this package #2

Merged
merged 9 commits into from
Jun 4, 2019

Conversation

metatoaster
Copy link
Member

This is a work in progress for this already very much work in progress prototype package. This is what happens when a JavaScript codebase is ignored for a couple years. Python doesn't have anywhere close to this level of integration issues because it doesn't have the myriad of barely working choices.

@metatoaster metatoaster force-pushed the separate_loader branch 3 times, most recently from 84faf3f to d4850b7 Compare May 15, 2019 01:25
@calmjs calmjs deleted a comment from coveralls May 15, 2019
@calmjs calmjs deleted a comment from coveralls May 15, 2019
@metatoaster metatoaster force-pushed the separate_loader branch 3 times, most recently from bbe6a1e to ad3b26c Compare May 29, 2019 02:03
- Provide a new test registry specific for the "legacy" (fuller feature)
  AMD-based tests.  Unfortuantely given that they are rather coupled to
  the features offered by RequireJS, these are now moved to their own
  registry.
- Remaining tests should be usable from webpack.
- With the introduction of this feature in calmjs-3.4.0, the nunja
  advice can always be applied to ensure that the pre-built version of
  the template be always enabled for the webpack toolchain given that it
  isn't optimised for other forms of dynamic usage.  This is in contrast
  to the RequireJS version where a more dynamic loading method may be
  kept enabled.
- This also show that a particular test case that would not have been
  migrated before the introduction of this feature under the standard
  testing regime.
- This ensures that webpack will not actually try to load that RequireJS
  dynamically generated module that would never resolve (thus webpack
  will fail); this is done such that forcible execution of these tests
  through the webpack toolchain (by the manual invocation of this
  registry with that) would not fail prematurely.
- Loading of this module via a variable would treat this as a dynamic
  load point and it exploits the fact that webpack can't try to resolve
  and fail on this.
- Renamed the nunja.mold.tests registry to nunja.mold.testing to signify
  that it isn't for as a provider for tests, but more for providing test
  molds that may be used for testing.  This also means that dependents
  will no longer pick this up, as the standard runner will no longer
  automatically include these molds.

- This allow a much finer control on how tests are run under the two
  currently implemented artifact bundlers.

- Changes made also ensure that all forms are executed through the
  standard calmjs runner (artifact runner to follow), while the full
  coverage is still unfortunately dependant on the async template loader
  given how it was originall implemented.

- Naturally, how those tests are skipped when conditions are unmet are
  also modified:

  - Skipped if the nunja.mold.testing registry isn't made available.
  - JavaScript testing frameworks just make this stupidly difficult, but
    returning a function that might or might not skip the test based on
    the condition works.
  - Also this is implemented in a way that allow the entire block to be
    excluded from coverage.
  - Given the huge number of tests to run, skip the artifact generation
    with the flag introduced in calmjs.dev-2.3.0.
- Ensure that requirejs is not a hard requirement when trying to query
  for an available template (such that this operation will not trigger
  an exception when built without it).
- Given the number of test cases across different test modules have the
  same skip conditions (i.e. when the required registry is missing), put
  them together where it make sense.
- Not sure if it's Python 2.7 or Node.js 8 causing issue on the build,
  but if we can rule out Node.js, Python 2 support for Nunja will be
  dropped on Windows.
- Adopting one of the previous prototypes but name them explicitly as to
  which module system they support, with the RequireJS being labeled as
  such and only assigned to NunjaLoader if it is available.
- Ensure that the appropriate things are included/excluded per default
  for each of the advice sets for toolchains.
@metatoaster metatoaster merged commit e2b6958 into calmjs:master Jun 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant