Migrate to webpack v5 #1184
Assignees
Comments
|
➤ Automation for Jira commented: The link to the corresponding Jira issue is https://ably.atlassian.net/browse/SDK-3522 |
lawrence-forooghian
added a commit
that referenced
this issue
Apr 17, 2023
The webpack v4 to v5 migration guide [1] says to "Upgrade webpack-cli to the latest available version". Presumably it means "the latest version compatible with webpack 4", which is this one [2]. Part of #1184. [1] https://webpack.js.org/migrate/5/#upgrade-webpack-4-and-its-pluginsloaders [2] https://github.com/webpack/webpack-cli/blob/master/CHANGELOG.md#500-2022-11-17
lawrence-forooghian
added a commit
that referenced
this issue
Apr 17, 2023
TODO check if this actually works, though — it's not clear to me if it will since there's a bunch of issues on the repo Part of #1184.
lawrence-forooghian
added a commit
that referenced
this issue
Apr 17, 2023
The latest version to support webpack 4 [1]. Part of #1184. [1] https://github.com/TypeStrong/ts-loader/blob/main/CHANGELOG.md#v900
lawrence-forooghian
added a commit
that referenced
this issue
Apr 17, 2023
Ran the following:
npm install webpack@latest \
webpack-cli@latest \
copy-webpack-plugin@latest \
tsconfig-paths-webpack-plugin@latest \
ts-loader@latest
Part of #1184.
lawrence-forooghian
added a commit
that referenced
this issue
Apr 20, 2023
Ran the following:
npm install webpack@latest \
webpack-cli@latest \
copy-webpack-plugin@latest \
tsconfig-paths-webpack-plugin@latest \
ts-loader@latest
Part of #1184.
This is the commit message #2:
remove polyfill configuration
let’s see if this still works
https://webpack.js.org/migrate/5/#clean-up-configuration
"If you are using something like node.fs: 'empty' replace it with
resolve.fallback.fs: false"
This is the commit message #3:
emit ES5 runtime code
> Webpack 4 used to only emit ES5 code. Webpack 5 can generate both ES5
and ES6/ES2015 code now.
https://webpack.js.org/blog/2020-10-10-webpack-5-release/#improved-code-generation
we seem to be assuming ES5 in our codebase (see gruntfile config of
ECMASCRIPT5 and “lib” in tsconfig.json) — without this, we had failure
of `npm run check-closure-compiler`
this config option doesn't exist in webpack 4
tested this commit in web worker, in https://github.com/lawrence-forooghian/ably-js-web-worker-example, a33a74d
tested this commit in react native, in https://github.com/lawrence-forooghian/ably-js-react-native-example, 38cfa55
TODO what about
/**
* Webpack v4 is used as Webpack v5 does not offer support for ES3 and creates issues for ES3 support such as discarding string literal keyword property names.
*/
what is our supported ES version? f2014f7 is "Update to ES5" but I can’t
find anything about the motivation, and we still mention ES3 above and
in the gruntfile.
TODO what about
> Without a browserslist webpack's runtime code uses ES2015 syntax (e.g., arrow function) to build smaller bundles. Hence you'll need to set target: ['web', 'es5'] to use the ES5 syntax for browsers (like IE11) which don't support ES2015 syntax .
>
> For Node.js, builds include the supported Node.js version in the target option and webpack will automatically figure out which syntax is supported, e.g. target: 'node8.6'.
what is our supported node version? what is our supported browser
version?
lawrence-forooghian
added a commit
that referenced
this issue
Apr 20, 2023
Ran the following:
npm install webpack@latest \
webpack-cli@latest \
copy-webpack-plugin@latest \
tsconfig-paths-webpack-plugin@latest \
ts-loader@latest
Part of #1184.
This is the commit message #2:
remove polyfill configuration
let’s see if this still works
https://webpack.js.org/migrate/5/#clean-up-configuration
"If you are using something like node.fs: 'empty' replace it with
resolve.fallback.fs: false"
This is the commit message #3:
emit ES5 runtime code
> Webpack 4 used to only emit ES5 code. Webpack 5 can generate both ES5
and ES6/ES2015 code now.
https://webpack.js.org/blog/2020-10-10-webpack-5-release/#improved-code-generation
we seem to be assuming ES5 in our codebase (see gruntfile config of
ECMASCRIPT5 and “lib” in tsconfig.json) — without this, we had failure
of `npm run check-closure-compiler`
this config option doesn't exist in webpack 4
tested this commit in web worker, in https://github.com/ably-labs/ably-js-react-native-example, commit 48eee78
tested this commit in react native, in https://github.com/ably-labs/ably-js-web-worker-example, commit 88ccaae
TODO what about
/**
* Webpack v4 is used as Webpack v5 does not offer support for ES3 and creates issues for ES3 support such as discarding string literal keyword property names.
*/
what is our supported ES version? f2014f7 is "Update to ES5" but I can’t
find anything about the motivation, and we still mention ES3 above and
in the gruntfile.
TODO what about
> Without a browserslist webpack's runtime code uses ES2015 syntax (e.g., arrow function) to build smaller bundles. Hence you'll need to set target: ['web', 'es5'] to use the ES5 syntax for browsers (like IE11) which don't support ES2015 syntax .
>
> For Node.js, builds include the supported Node.js version in the target option and webpack will automatically figure out which syntax is supported, e.g. target: 'node8.6'.
what is our supported node version? what is our supported browser
version?
lawrence-forooghian
added a commit
that referenced
this issue
Apr 20, 2023
Ran the following:
npm install webpack@latest \
webpack-cli@latest \
copy-webpack-plugin@latest \
tsconfig-paths-webpack-plugin@latest \
ts-loader@latest
Part of #1184.
This is the commit message #2:
remove polyfill configuration
let’s see if this still works
https://webpack.js.org/migrate/5/#clean-up-configuration
"If you are using something like node.fs: 'empty' replace it with
resolve.fallback.fs: false"
This is the commit message #3:
emit ES5 runtime code
> Webpack 4 used to only emit ES5 code. Webpack 5 can generate both ES5
and ES6/ES2015 code now.
https://webpack.js.org/blog/2020-10-10-webpack-5-release/#improved-code-generation
we seem to be assuming ES5 in our codebase (see gruntfile config of
ECMASCRIPT5 and “lib” in tsconfig.json) — without this, we had failure
of `npm run check-closure-compiler`
this config option doesn't exist in webpack 4
tested this commit in web worker, in https://github.com/ably-labs/ably-js-react-native-example, commit 48eee78
tested this commit in react native, in https://github.com/ably-labs/ably-js-web-worker-example, commit 88ccaae
TODO what about
/**
* Webpack v4 is used as Webpack v5 does not offer support for ES3 and creates issues for ES3 support such as discarding string literal keyword property names.
*/
what is our supported ES version? f2014f7 is "Update to ES5" but I can’t
find anything about the motivation, and we still mention ES3 above and
in the gruntfile.
#839 says "Now we no longer
advertise support for IE8 (or ES3) we can take this upgrade."
TODO what about
> Without a browserslist webpack's runtime code uses ES2015 syntax (e.g., arrow function) to build smaller bundles. Hence you'll need to set target: ['web', 'es5'] to use the ES5 syntax for browsers (like IE11) which don't support ES2015 syntax .
>
> For Node.js, builds include the supported Node.js version in the target option and webpack will automatically figure out which syntax is supported, e.g. target: 'node8.6'.
what is our supported node version? what is our supported browser
version?
lawrence-forooghian
added a commit
that referenced
this issue
Apr 20, 2023
The webpack v4 to v5 migration guide [1] says to upgrade plugins to the latest version which supports webpack 4. 4.0.1 is the latest version of this plugin, and it appears to support both webpack 4 and 5. Part of #1184. [1] https://webpack.js.org/migrate/5/#upgrade-webpack-4-and-its-pluginsloaders
lawrence-forooghian
added a commit
that referenced
this issue
Apr 20, 2023
The webpack v4 to v5 migration guide [1] says to upgrade loaders to the latest version which supports webpack 4, which in the case of this loader is this version [2]. Part of #1184. [1] https://webpack.js.org/migrate/5/#upgrade-webpack-4-and-its-pluginsloaders [2] https://github.com/TypeStrong/ts-loader/blob/main/CHANGELOG.md#v900
lawrence-forooghian
added a commit
that referenced
this issue
Apr 20, 2023
Part of our preparations for upgrading to webpack 5. 5.0.0 is the latest version of this package, and its README states that it supports both webpack 4 and 5. Part of #1184.
lawrence-forooghian
added a commit
that referenced
this issue
Apr 20, 2023
Ran the following:
npm install webpack@latest \
webpack-cli@latest \
copy-webpack-plugin@latest \
tsconfig-paths-webpack-plugin@latest \
ts-loader@latest
Then, performed the following changes to get the build green:
- Configured webpack to emit ES5 code (`target` configuration)
As described in [1], webpack 4 emitted ES5 code, but webpack 5 emits
ES6 code by default. It’s not super clear to me which version of ES
we’re actually aiming to emit, since CONTRIBUTING.md, webpack.config.js,
and a comment in Gruntfile.js suggest we’re aiming for ES3. I think
these might just be outdated comments, though, since f2014f7 ("Update to
ES5") and [2] ("Now we no longer advertise support for IE8 (or ES3)")
suggest that we’ve dropped ES3 support.
Anyway, here I’ve configured webpack to emit ES5 code, to match the
webpack 4 behaviour and to keep `npm run check-closure-compiler`
passing.
- Removed config of Node-like polyfills (`node` configuration removed or
replaced with `resolve.fallback`)
As described in [3], webpack no longer automatically applies polyfills
for Node.js APIs when targeting frontend environments. This means that
we can remove the config telling it not to polyfill `Buffer`, and update
to the new `fallback` syntax for telling it to stub the Crypto module
with an empty object (as instructed by [4], "If you are using something
like node.fs: 'empty' replace it with resolve.fallback.fs: false").
As Owen said in #1184 "As part of this work we will need to manually
test that the lib still works in react-native and web workers, since
these aren't covered by automated tests." I’ve tested this in a couple
of small example apps [5] and [6], which just check that they’re able to
import ably-js and publish / receive a message.
[1] https://webpack.js.org/blog/2020-10-10-webpack-5-release/#improved-code-generation
[2] #839
[3] https://webpack.js.org/blog/2020-10-10-webpack-5-release/#automatic-nodejs-polyfills-removed
[4] https://webpack.js.org/migrate/5/#clean-up-configuration
[5] https://github.com/ably-labs/ably-js-react-native-example, commit 48eee78
[6] https://github.com/ably-labs/ably-js-web-worker-example, commit 88ccaae
lawrence-forooghian
added a commit
that referenced
this issue
Apr 20, 2023
Ran the following:
npm install webpack@latest \
webpack-cli@latest \
copy-webpack-plugin@latest \
tsconfig-paths-webpack-plugin@latest \
ts-loader@latest
Then, performed the following changes to get the build green:
- Configured webpack to emit ES5 code (`target` configuration)
As described in [1], webpack 4 emitted ES5 code, but webpack 5 emits
ES6 code by default. It’s not super clear to me which version of ES
we’re actually aiming to emit, since CONTRIBUTING.md, webpack.config.js,
and a comment in Gruntfile.js suggest we’re aiming for ES3. I think
these might just be outdated comments, though, since f2014f7 ("Update to
ES5") and [2] ("Now we no longer advertise support for IE8 (or ES3)")
suggest that we’ve dropped ES3 support.
Anyway, here I’ve configured webpack to emit ES5 code, to match the
webpack 4 behaviour and to keep `npm run check-closure-compiler`
passing.
- Removed config of Node-like polyfills (`node` configuration removed or
replaced with `resolve.fallback`)
As described in [3], webpack no longer automatically applies polyfills
for Node.js APIs when targeting frontend environments. If you wish to
apply polyfills, you need to opt-in though the the new
`resolve.fallback` config.
This means that we can remove the config telling it not to polyfill
`Buffer`. As for the current behaviour of stubbing the Crypto module
with an empty object, we achieve this with the `resolve.fallback.crypto:
false` syntax which, whilst not properly documented in [4] at time of
writing, is instructed by [5] ("If you are using something like node.fs:
'empty' replace it with resolve.fallback.fs: false") and described in
an error message in the webpack code [6].
As Owen said in #1184 "As part of this work we will need to manually
test that the lib still works in react-native and web workers, since
these aren't covered by automated tests." I’ve tested this in a couple
of small example apps [7] and [8], which just check that they’re able to
import ably-js and publish / receive a message.
[1] https://webpack.js.org/blog/2020-10-10-webpack-5-release/#improved-code-generation
[2] #839
[3] https://webpack.js.org/blog/2020-10-10-webpack-5-release/#automatic-nodejs-polyfills-removed
[4] https://webpack.js.org/configuration/resolve/#resolvefallback
[5] https://webpack.js.org/migrate/5/#clean-up-configuration
[6] https://github.com/webpack/webpack/blob/770a5a9cae8e2eddd5ca015efd06847e37480f45/lib/ModuleNotFoundError.js#L70-L72
[7] https://github.com/ably-labs/ably-js-react-native-example, commit 48eee78
[8] https://github.com/ably-labs/ably-js-web-worker-example, commit 88ccaae
lawrence-forooghian
added a commit
that referenced
this issue
Apr 20, 2023
Ran the following:
npm install webpack@latest \
webpack-cli@latest \
copy-webpack-plugin@latest \
tsconfig-paths-webpack-plugin@latest \
ts-loader@latest
Then, performed the following changes to get the build green:
- Configured webpack to emit ES5 code (`target` configuration)
As described in [1], webpack 4 emitted ES5 code, but webpack 5 emits
ES6 code by default. It’s not super clear to me which version of ES
we’re actually aiming to emit, since CONTRIBUTING.md, webpack.config.js,
and a comment in Gruntfile.js suggest we’re aiming for ES3. I think
these might just be outdated comments, though, since f2014f7 ("Update to
ES5") and [2] ("Now we no longer advertise support for IE8 (or ES3)")
suggest that we’ve dropped ES3 support.
Anyway, here I’ve configured webpack to emit ES5 code, to match the
webpack 4 behaviour and to keep `npm run check-closure-compiler`
passing.
- Removed config of Node-like polyfills (`node` configuration removed or
replaced with `resolve.fallback`)
As described in [3], webpack no longer automatically applies polyfills
for Node.js APIs when targeting frontend environments. If you wish to
apply polyfills, you need to opt-in though the the new
`resolve.fallback` config.
This means that we can remove the config telling it not to polyfill
`Buffer`. As for the current behaviour of stubbing the Crypto module
with an empty object, we achieve this with the `resolve.fallback.crypto:
false` syntax which, whilst not properly documented in [4] at time of
writing, is instructed by [5] ("If you are using something like node.fs:
'empty' replace it with resolve.fallback.fs: false") and described in
an error message in the webpack code [6].
As Owen said in #1184 "As part of this work we will need to manually
test that the lib still works in react-native and web workers, since
these aren't covered by automated tests." I’ve tested this in a couple
of small example apps [7] and [8], which just check that they’re able to
import ably-js and publish / receive a message.
[1] https://webpack.js.org/blog/2020-10-10-webpack-5-release/#improved-code-generation
[2] #839
[3] https://webpack.js.org/blog/2020-10-10-webpack-5-release/#automatic-nodejs-polyfills-removed
[4] https://webpack.js.org/configuration/resolve/#resolvefallback
[5] https://webpack.js.org/migrate/5/#clean-up-configuration
[6] https://github.com/webpack/webpack/blob/770a5a9cae8e2eddd5ca015efd06847e37480f45/lib/ModuleNotFoundError.js#L70-L72
[7] https://github.com/ably-labs/ably-js-react-native-example, commit 48eee78
[8] https://github.com/ably-labs/ably-js-web-worker-example, commit 88ccaae
lawrence-forooghian
added a commit
that referenced
this issue
Apr 24, 2023
This was pointed out by webpack 5 whilst doing the upgrade for #1184.
lawrence-forooghian
added a commit
that referenced
this issue
Apr 24, 2023
The webpack v4 to v5 migration guide [1] says to "Upgrade webpack-cli to the latest available version". Presumably it means "the latest version compatible with webpack 4", which is this one [2]. Part of #1184. [1] https://webpack.js.org/migrate/5/#upgrade-webpack-4-and-its-pluginsloaders [2] https://github.com/webpack/webpack-cli/blob/master/CHANGELOG.md#500-2022-11-17
lawrence-forooghian
added a commit
that referenced
this issue
Apr 24, 2023
The webpack v4 to v5 migration guide [1] says to upgrade plugins to the latest version which supports webpack 4. 4.0.1 is the latest version of this plugin, and it appears to support both webpack 4 and 5. Part of #1184. [1] https://webpack.js.org/migrate/5/#upgrade-webpack-4-and-its-pluginsloaders
lawrence-forooghian
added a commit
that referenced
this issue
Apr 24, 2023
The webpack v4 to v5 migration guide [1] says to upgrade loaders to the latest version which supports webpack 4, which in the case of this loader is this version [2]. Part of #1184. [1] https://webpack.js.org/migrate/5/#upgrade-webpack-4-and-its-pluginsloaders [2] https://github.com/TypeStrong/ts-loader/blob/main/CHANGELOG.md#v900
lawrence-forooghian
added a commit
that referenced
this issue
Apr 24, 2023
Part of our preparations for upgrading to webpack 5. 5.0.0 is the latest version of this package, and its README states that it supports both webpack 4 and 5. Part of #1184.
lawrence-forooghian
added a commit
that referenced
this issue
Apr 24, 2023
Ran the following:
npm install webpack@latest \
webpack-cli@latest \
copy-webpack-plugin@latest \
tsconfig-paths-webpack-plugin@latest \
ts-loader@latest
Then, performed the following changes to get the build green:
- Configured webpack to emit ES5 code (`target` configuration)
As described in [1], webpack 4 emitted ES5 code, but webpack 5 emits
ES6 code by default. However, as documented in CONTRIBUTING.md, and as
expected by `npm run check-closure-compiler`, we aim to use ES5 in the
code we ship. So, configure webpack to emit ES5 code.
- Removed config of Node-like polyfills (`node` configuration removed or
replaced with `resolve.fallback`)
As described in [2], webpack no longer automatically applies polyfills
for Node.js APIs when targeting frontend environments. If you wish to
apply polyfills, you need to opt-in though the the new
`resolve.fallback` config.
This means that we can remove the config telling it not to polyfill
`Buffer`. As for the current behaviour of stubbing the Crypto module
with an empty object, we achieve this with the `resolve.fallback.crypto:
false` syntax which, whilst not properly documented in [3] at time of
writing, is instructed by [4] ("If you are using something like node.fs:
'empty' replace it with resolve.fallback.fs: false") and described in
an error message in the webpack code [5].
As Owen said in #1184 "As part of this work we will need to manually
test that the lib still works in react-native and web workers, since
these aren't covered by automated tests." I’ve tested this in a couple
of small example apps [6] and [7], which just check that they’re able to
import ably-js and publish / receive a message.
[1] https://webpack.js.org/blog/2020-10-10-webpack-5-release/#improved-code-generation
[2] https://webpack.js.org/blog/2020-10-10-webpack-5-release/#automatic-nodejs-polyfills-removed
[3] https://webpack.js.org/configuration/resolve/#resolvefallback
[4] https://webpack.js.org/migrate/5/#clean-up-configuration
[5] https://github.com/webpack/webpack/blob/770a5a9cae8e2eddd5ca015efd06847e37480f45/lib/ModuleNotFoundError.js#L70-L72
[6] https://github.com/ably-labs/ably-js-react-native-example, commit 05a0177
[7] https://github.com/ably-labs/ably-js-web-worker-example, commit 62621db
|
Closed in #1201. |
lawrence-forooghian
added a commit
that referenced
this issue
Apr 26, 2023
The webpack v4 to v5 migration guide [1] says to "Upgrade webpack-cli to the latest available version". Presumably it means "the latest version compatible with webpack 4", which is this one [2]. Part of #1184. [1] https://webpack.js.org/migrate/5/#upgrade-webpack-4-and-its-pluginsloaders [2] https://github.com/webpack/webpack-cli/blob/master/CHANGELOG.md#500-2022-11-17
lawrence-forooghian
added a commit
that referenced
this issue
Apr 26, 2023
The webpack v4 to v5 migration guide [1] says to upgrade plugins to the latest version which supports webpack 4. 4.0.1 is the latest version of this plugin, and it appears to support both webpack 4 and 5. Part of #1184. [1] https://webpack.js.org/migrate/5/#upgrade-webpack-4-and-its-pluginsloaders
lawrence-forooghian
added a commit
that referenced
this issue
Apr 26, 2023
The webpack v4 to v5 migration guide [1] says to upgrade loaders to the latest version which supports webpack 4, which in the case of this loader is this version [2]. Part of #1184. [1] https://webpack.js.org/migrate/5/#upgrade-webpack-4-and-its-pluginsloaders [2] https://github.com/TypeStrong/ts-loader/blob/main/CHANGELOG.md#v900
lawrence-forooghian
added a commit
that referenced
this issue
Apr 26, 2023
Part of our preparations for upgrading to webpack 5. 5.0.0 is the latest version of this package, and its README states that it supports both webpack 4 and 5. Part of #1184.
lawrence-forooghian
added a commit
that referenced
this issue
Apr 26, 2023
Ran the following:
npm install webpack@latest \
webpack-cli@latest \
copy-webpack-plugin@latest \
tsconfig-paths-webpack-plugin@latest \
ts-loader@latest
Then, performed the following changes to get the build green:
- Configured webpack to emit ES5 code (`target` configuration)
As described in [1], webpack 4 emitted ES5 code, but webpack 5 emits
ES6 code by default. However, as documented in CONTRIBUTING.md, and as
expected by `npm run check-closure-compiler`, we aim to use ES5 in the
code we ship. So, configure webpack to emit ES5 code.
- Removed config of Node-like polyfills (`node` configuration removed or
replaced with `resolve.fallback`)
As described in [2], webpack no longer automatically applies polyfills
for Node.js APIs when targeting frontend environments. If you wish to
apply polyfills, you need to opt-in though the the new
`resolve.fallback` config.
This means that we can remove the config telling it not to polyfill
`Buffer`. As for the current behaviour of stubbing the Crypto module
with an empty object, we achieve this with the `resolve.fallback.crypto:
false` syntax which, whilst not properly documented in [3] at time of
writing, is instructed by [4] ("If you are using something like node.fs:
'empty' replace it with resolve.fallback.fs: false") and described in
an error message in the webpack code [5].
As Owen said in #1184 "As part of this work we will need to manually
test that the lib still works in react-native and web workers, since
these aren't covered by automated tests." I’ve tested this in a couple
of small example apps [6] and [7], which just check that they’re able to
import ably-js and publish / receive a message.
[1] https://webpack.js.org/blog/2020-10-10-webpack-5-release/#improved-code-generation
[2] https://webpack.js.org/blog/2020-10-10-webpack-5-release/#automatic-nodejs-polyfills-removed
[3] https://webpack.js.org/configuration/resolve/#resolvefallback
[4] https://webpack.js.org/migrate/5/#clean-up-configuration
[5] https://github.com/webpack/webpack/blob/770a5a9cae8e2eddd5ca015efd06847e37480f45/lib/ModuleNotFoundError.js#L70-L72
[6] https://github.com/ably-labs/ably-js-react-native-example, commit 05a0177
[7] https://github.com/ably-labs/ably-js-web-worker-example, commit 62621db
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
See the official migration guide and previous attempt.
This work should land in a new integration branch called
integration/v2As part of this work we will need to manually test that the lib still works in react-native and web workers, since these aren't covered by automated tests.
The text was updated successfully, but these errors were encountered: