marko 5.31.5 → 5.31.7

Sign up to get free protection for your applications and to get access to all the features.
@@ -6,44 +6,35 @@ This means you should complete a step and get it merged back into master fairly
6
6
 
7
7
  If you do decide to pause and later jump in where you left off, be sure to repeat Step 0 first 😉.
8
8
 
9
- ## Step 0 - Ensure you're in a working state
10
-
11
- Run your application and tests to ensure your project is in a working state. There's little worse than finding an issue after you've started the upgrade process only to figure out the issue existed beforehand.
12
-
13
- ## Step 1 - Upgrade to latest 4.x
9
+ ## Step 0 - Ensure you're in a working state on the latest version of Marko 4
14
10
 
15
11
  Before we start, you'll want to make sure that you are already on the latest `4.x` release of `marko`.
16
12
 
17
- ```
13
+ ```bash
14
+ # Upgrade using npm
18
15
  npm install marko@^4
19
- ```
20
-
21
- or
22
16
 
23
- ```
17
+ # Or with yarn
24
18
  yarn upgrade marko@^4
25
19
  ```
26
20
 
27
- > Note: Do NOT run `npm install marko` (without the `@^4`). This will put you on Marko 5 and we're not quite there yet.
28
-
29
- ## Step 2 - Deal with deprecations
30
-
31
- Run your application and tests and ensure that there are no deprecation warnings logged to the console. If there are, you should follow the instructions in the deprecation messages to avoid the deprecated pattern and migrate to the recommended pattern.
32
-
33
- Additionally, any deprecation warnings that start with `MIGRATION` are automatically migratable by [`marko migrate`](https://github.com/marko-js/cli/blob/master/packages/migrate/README.md). Most migrations are 100% safe and will run automatically. However, there are a few migrations which are considered unsafe: they may only get you 90% of the way there. These migrations will prompt and ask if you want to run the migration. It is highly recommended to run these only on a single component at a time and then finish the migration manually using the guide below so that your app is always in a working state.
21
+ > **Warning**
22
+ > Do _not_ run `npm install marko` (without the `@^4`). This will put you on Marko 5 and we're not quite there yet.
34
23
 
35
- > **Note**: Deprecations related to `marko-widgets` are not necessary to address before upgrading.
24
+ Run your application and tests to ensure your project is in a working state. There's little worse than finding an issue after you've started the upgrade process only to figure out the issue existed beforehand.
36
25
 
37
- ## Step 3 - Upgrade dependencies
26
+ ## Step 1 - Upgrade dependencies
38
27
 
39
28
  Before upgrading to Marko 5, it is recommended to make sure that your Marko-related dependencies are up-to-date. Many packages have versions that support both Marko 4 and Marko 5. If one of your dependencies doesn't have a version that supports both, you'll need to wait to upgrade it until you're upgrading Marko.
40
29
 
41
30
  After upgrading, run your application and tests to ensure that everything is still working as intended. If there are any issues, please refer to the changelogs of the modules you just upgraded to see if you need to make any changes within your app to accommodate the new versions.
42
31
 
43
- ## Step 4 - Upgrade marko
32
+ ## Step 2 - Upgrade Marko
44
33
 
45
34
  Phew! With all the prep out of the way we're finally ready to upgrade `marko`!
46
35
 
36
+ ### Install Modules
37
+
47
38
  Note that some features removed in Marko 4 do not log deprecations since they do not need to be resolved to get up and running with Marko 5. However for Marko 5 to support some of the features removed after Marko 4 you need to install a `compat` module.
48
39
 
49
40
  There are currently two `compat` modules you can install, one which supports the `marko-widget`'s api from Marko@3 and one with just the compat needed for Marko@4 components.
@@ -68,13 +59,53 @@ npm install marko@^5 @marko/compiler @marko/compat-v4
68
59
  yarn install marko@^5 @marko/compiler @marko/compat-v4
69
60
  ```
70
61
 
71
- > **Note**: Marko 5 has changed to using ES Modules. This means if you are using CJS modules to `require` a Marko template you will need to use the `.default` property exported. When using @marko/compat-v4 this is handled automatically.
72
- >
73
- > ```js
74
- > const template = require("./template.marko");
75
- > // …should become:
76
- > const template = require("./template.marko").default;
77
- >
78
- > // If already using ES Modules, things remain the same:
79
- > import template from "./template.marko";
80
- > ```
62
+ ### App entry updates
63
+
64
+ If you're bundling your server code (common with `webpack` setups), your entry will be your bundler config.
65
+ Otherwise it's probably something like `index.js` or `server.js` near your project root.
66
+
67
+ - Register your compat module globally so that any dependencies also run through the compat layer:
68
+
69
+ ```js
70
+ require("@marko/compiler").taglib.register("marko-widgets");
71
+ ```
72
+
73
+ > **Note**
74
+ > if using `webpack` or `rollup` this line should also be added you your bundler config file
75
+
76
+ > **Note**
77
+ > if using `jest` you should pass the [`register` option](https://github.com/marko-js/jest#customizing-the-marko-compiler) which requires the latest version of `jest` and `@marko/jest`
78
+
79
+ - _If you're using `babel`_, Marko 5 picks up on your babel config which could change behavior. You may want to configure Marko to ignore your babel config:
80
+ ```js
81
+ require("@marko/compiler").configure({
82
+ babelConfig: {
83
+ babelrc: false,
84
+ configFile: false,
85
+ },
86
+ });
87
+ ```
88
+ If you do this, you'll also want also want to pass the `babelConfig` option to your bundler plugin (`lasso-marko`, `@marko/webpack`, `@marko/rollup`)
89
+
90
+ ### Submodule updates
91
+
92
+ A couple submodules no longer exist in Marko 5:
93
+
94
+ - _If you're using the require hook_, replace `marko/node-require`:
95
+ ```diff
96
+ - require('marko/node-require').install();
97
+ + require('@marko/compiler/register');
98
+ ```
99
+ - _If you're using `browser-refresh`_, including the runtime is no longer necessary:
100
+ ```diff
101
+ - require('marko/browser-refresh').enable();
102
+ ```
103
+
104
+ ## Step 3 - Optional, but recommended: deal with deprecations
105
+
106
+ Run your application and tests and ensure that there are no deprecation warnings logged to the console. If there are, you should follow the instructions in the deprecation messages to avoid the deprecated pattern and migrate to the recommended pattern.
107
+
108
+ Additionally, any deprecation warnings that start with `MIGRATION` are automatically migratable by [`marko migrate`](https://github.com/marko-js/cli/blob/master/packages/migrate/README.md). Most migrations are 100% safe and will run automatically. However, there are a few migrations which are considered unsafe: they may only get you 90% of the way there. These migrations will prompt and ask if you want to run the migration. It is highly recommended to run these only on a single component at a time and then finish the migration manually using the guide below so that your app is always in a working state.
109
+
110
+ > **Note**
111
+ > The [TagsAPI](https://dev.to/ryansolid/introducing-the-marko-tags-api-preview-37o4) is becoming stable soon. Deprecations related to `marko-widgets`, might be worth holding off on rather than migrating these widgets to the Class Components API.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "marko",
3
- "version": "5.31.5",
3
+ "version": "5.31.7",
4
4
  "description": "UI Components + streaming, async, high performance, HTML templating for Node.js and the browser.",
5
5
  "keywords": [
6
6
  "front-end",
@@ -65,7 +65,7 @@
65
65
  },
66
66
  "dependencies": {
67
67
  "@marko/compiler": "^5.33.1",
68
- "@marko/translator-default": "^5.31.1",
68
+ "@marko/translator-default": "^5.31.2",
69
69
  "app-module-path": "^2.2.0",
70
70
  "argly": "^1.2.0",
71
71
  "browser-refresh-client": "1.1.4",