marko 5.31.5 → 5.31.7

package/docs/marko-5-upgrade.md

@@ -6,44 +6,35 @@ This means you should complete a step and get it merged back into master fairly
 
 If you do decide to pause and later jump in where you left off, be sure to repeat Step 0 first 😉.
 
-## Step 0 - Ensure you're in a working state
-
-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.
-
-## Step 1 - Upgrade to latest 4.x
+## Step 0 - Ensure you're in a working state on the latest version of Marko 4
 
 Before we start, you'll want to make sure that you are already on the latest `4.x` release of `marko`.
 
-```
+```bash
+# Upgrade using npm
 npm install marko@^4
-```
-
-or
 
-```
+# Or with yarn
 yarn upgrade marko@^4
 ```
 
-> Note: Do NOT run `npm install marko` (without the `@^4`). This will put you on Marko 5 and we're not quite there yet.
-
-## Step 2 - Deal with deprecations
-
-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.
-
-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.
+> **Warning**
+> Do _not_ run `npm install marko` (without the `@^4`). This will put you on Marko 5 and we're not quite there yet.
 
-> **Note**: Deprecations related to `marko-widgets` are not necessary to address before upgrading.
+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.
 
-## Step 3 - Upgrade dependencies
+## Step 1 - Upgrade dependencies
 
 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.
 
 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.
 
-## Step 4 - Upgrade marko
+## Step 2 - Upgrade Marko
 
 Phew! With all the prep out of the way we're finally ready to upgrade `marko`!
 
+### Install Modules
+
 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.
 
 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
 yarn install marko@^5 @marko/compiler @marko/compat-v4
 ```
 
-> **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.
->
-> ```js
-> const template = require("./template.marko");
-> // …should become:
-> const template = require("./template.marko").default;
->
-> // If already using ES Modules, things remain the same:
-> import template from "./template.marko";
-> ```
+### App entry updates
+
+If you're bundling your server code (common with `webpack` setups), your entry will be your bundler config.
+Otherwise it's probably something like `index.js` or `server.js` near your project root.
+
+- Register your compat module globally so that any dependencies also run through the compat layer:
+
+  ```js
+  require("@marko/compiler").taglib.register("marko-widgets");
+  ```
+
+  > **Note**
+  > if using `webpack` or `rollup` this line should also be added you your bundler config file
+
+  > **Note**
+  > 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`
+
+- _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:
+  ```js
+  require("@marko/compiler").configure({
+    babelConfig: {
+      babelrc: false,
+      configFile: false,
+    },
+  });
+  ```
+  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`)
+
+### Submodule updates
+
+A couple submodules no longer exist in Marko 5:
+
+- _If you're using the require hook_, replace `marko/node-require`:
+  ```diff
+  - require('marko/node-require').install();
+  + require('@marko/compiler/register');
+  ```
+- _If you're using `browser-refresh`_, including the runtime is no longer necessary:
+  ```diff
+  - require('marko/browser-refresh').enable();
+  ```
+
+## Step 3 - Optional, but recommended: deal with deprecations
+
+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.
+
+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.
+
+> **Note**
+> 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

@@ -1,6 +1,6 @@
 {
     "name": "marko",
-    "version": "5.31.5",
+    "version": "5.31.7",
     "description": "UI Components + streaming, async, high performance, HTML templating for Node.js and the browser.",
     "keywords": [
         "front-end",
@@ -65,7 +65,7 @@
     },
     "dependencies": {
         "@marko/compiler": "^5.33.1",
-        "@marko/translator-default": "^5.31.1",
+        "@marko/translator-default": "^5.31.2",
         "app-module-path": "^2.2.0",
         "argly": "^1.2.0",
         "browser-refresh-client": "1.1.4",