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

Provide support for webpack>=2.6 #6

Merged
merged 23 commits into from Aug 22, 2018
Merged

Conversation

metatoaster
Copy link
Member

@metatoaster metatoaster commented Aug 17, 2018

Implemented a substantial number of infrastructure to ensure that webpack-4 is supported, while not removing the ability to support most webpack-2 and even webpack-3 usage in conjunction with this integration library.

Notable changes and implementation details includes:

  • Convert configuration file generation for the setup of both webpack and karma from a naive JSON/string template approach to one that make use of a full JavaScript parser (through calmjs.parse) such that features may be enabled/disabled or downgraded to an appropriate form.
  • Ensure that if webpack fails to compile an artifact in the context of karma, it kills the karma process when executed through the calmjs webpack runtime, as interactions between later versions of webpack, karma-webpack and/or karma no longer result in a condition where the karma process will terminate with the singleRun: true configured.

Task should also be done as part of getting this merged:

  • Update documentation for the supported webpack versions (and examples with relevant output)
  • Rebase the webpack version update to 4 to a separate branch, to avoid forcing a 2.0.0 release
  • Create a 1.2.0 release.

- The version is tracked to the major.minor for the release for the
  mean time, until a more loose setting can be derived.
- Only test equality of prebuilts for those versions available.
- Given that webpack 4 provides a set of new keys which may or may not
  be useful, provide some base support for that such that by default,
  the warning generated may be silenced if that version is provided.
- This paves the way to address differences between webpack versions,
  such that a wider range of webpack version may be used, so that the
  expected behaviors may be more easily preserved whenever possible.
- This permit a common and dedicated access to the same method of
  acquiring the location of the webpack binary in the same manner as
  the way the WebpackToolchain does it.
- Hook the karma and toolchain config generation to make use of the
  webpack configuration setup.
- Given that window instead of this is now passed in webpack 4, change
  around how the invocation is done in node such that the previously
  established behavior is maintained when it comes to the short-circuit
  testing through Node.js.
- Some versions of webpack-karma + webpack will simply sit around idle
  forever whenever webpack fails to build.  This injects a plugin into
  the configuration such that whenever webpack fails to build, have it
  kill itself.
- Rather than making the assumption about the positioning of the files,
  extract the first object present in the source as that is currently
  where the generated base configuration definition sits.
- Implement the base datatypes to ease the creation, manipulation and
  management of webpack configuration scripts to be generated.
- Provide a helper function that will locate a property and inject the
  relevant array items into the object, or assign the array as new
  property; this is for internal use as the implementation is extremely
  naive.
- Introduce a __webpack_target__ key to the configuration mapping such
  that the information is persisted when the mapping instance is casted
  to a standard dictionary.
- Also no longer store the ast too prematurely, and break up the whole
  serialization process into separate methods to permit better reuse.
- Provide a function that will process the webpack config object AST
  such that version specific flags are produced to avoid conflicts.
@metatoaster metatoaster force-pushed the webpack_4 branch 2 times, most recently from ff882aa to e3b0a0b Compare August 20, 2018 02:15
- Formalize certain method names such that the mapping (and maybe also
  the generic sequence, later) may be used in conjunction with other
  instances embedded inside it.
- Parent class inherits all common dunder methods.
- Also require calmjs-3.3.1 (even though this was not created at the
  point of the original creation timestamp of this commit).
- Have the conversion be done in the same manner (API) as the mapping
  type.
- Also note that the type checking (isinstance) is now done using the
  individually imported asttypes class from the original module, such
  that the correct subclass hierarchy is applied.
- The webpack plugin class now subclass from that.
- Keeping this plugin in place for now.
- Follow the usage patterns of the ConfigMapping and have the webpack
  version be one of the reserved keys.
- Modified how attributes are initialised so that the _setup function
  can also define the initial default values for the mapping.
- Include the required keys for webpack-4.0.0 to ensure functionality of
  webpack-2.0.0 is preserved (e.g. no default mode or devtool).
- Remove the prototype webpack version custom configuration code.
- Remove old template definitions.
- Remove some unnecessary configuration serialization matching checks as
  these are done inside the configuration classes (and that those checks
  are hard to port given the variation in webpack versions, which are
  tested separate).
- Also a bump to the minimum Node.js version is required, given that the
  testing through karma requires features only supported by Node.js>6;
  also that Node.js 4 has been EOL'd.
- Also bump calmjs.dev to 2.2.2, as that implements some required fixes
  to ensure karma actually works with the new custom configuration that
  is generated by this package.
- This version of karma-webpack may have resolved some issues with
  working with newer versions of webpack.
- Moved 2.6 to 2.7 examples as there were no changes, and this reflects
  the current version number.
- Also include new example data 3.12, 4.0 and 4.16 as there were various
  semantic changes between all of these, and to increase sample size of
  supported configurations and outputs.
- While I normally stitch these back in via rebase, the fact that
  Python 2 is starting to take extra work and these changes highlight
  that fact.
- This was a legacy from before there was a `which` specifically for
  getting a binary from node_modules for environments that do not have a
  node_modules binary directory in PATH.
- Given the static assignment for a global instance, this hard static
  assignment will stop alternative environments from being used if a
  directory change occured, forcing the default instance to depend on
  that one directory.
- Correct a related test case that was demonstrating the symptom of this
  issue and maintain this as part of the internal documentation.
- There may be situations that the working directory is in a symlink of
  some kind and then webpack gets into a situation where it still cannot
  find itself.  This patch address that by calling the version finding
  routine also in the same manner as the resolution for this.
- Also document exactly why this is done.
- Should probably set up a different test case where the Python
  environment is located inside a subdirectory on the parent of that
  node_modules...
@metatoaster metatoaster changed the title Provide support for webpack~4.16.0 Provide support for webpack>=2.6 Aug 21, 2018
- Not pinning to webpack-4 until calmjs.webpack-2.0.0.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant