❓Question

I'm using the simple-oauth2 node module on the server side. It uses the (new) [private] class field syntax. Webpack tells me that it cannot parse the associated files as follows:

throw new Error("Module parse failed: Unexpected character '#' (19:2)\nYou may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders\n| \n| module.exports = class Client {\n>   #config = null;\n|   #client = null;\n| ");
      ^
Module parse failed: Unexpected character '#' (19:2)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
| 
| module.exports = class Client {
>   #config = null;
|   #client = null;
|
    at Object.../server/node_modules/simple-oauth2/lib/client/client.js (.../app/build/server.js:507057:7)
    at __webpack_require__ (,,,/app/webpack/bootstrap:754:1)

Is that something that's supposed to be supported? If so, where am I going wrong in my config? babel/webpack? I tried razzle@canary but no luck either.

Thanks for any insight and advice :)

I have configured nginx reverse proxy to redirect 3000 and 3001 for default create-razzle-app. The page loads but is immediately replaced with empty root div.

.env file

HOST='apps.syntapse.co.uk'
PORT=3000
VERBOSE='true'
NODE_ENV='development'
BUILD_TARGET='client'
PUBLIC_PATH='https://apps.syntapse.co.uk/razzle'
CLIENT_PUBLIC_PATH='https://apps.syntapse.co.uk/razzle-dev'

nginx server definition for the redirects:

server {
      listen 80;
      server_name apps.syntapse.co.uk;
      location ^~ /razzle-dev {
         proxy_pass http://0.0.0.0:3001/;
         proxy_http_version 1.1;
         proxy_set_header Upgrade $http_upgrade;
         proxy_set_header Connection 'upgrade';
         proxy_set_header Host $host;
         proxy_cache_bypass $http_upgrade;
      }    	
      location ^~ /razzle {
         proxy_pass http://0.0.0.0:3000/;
         proxy_http_version 1.1;
         proxy_set_header Upgrade $http_upgrade;
         proxy_set_header Connection 'upgrade';
         proxy_set_header Host $host;
         proxy_cache_bypass $http_upgrade;
      }    	
 }

so that the razzle build script can produce a development build (which is sometimes useful for testing) using just a parameter --node-env=development

see #1289

Tasks

• [ ] the modified build script also seems to start a background process that still writes to the terminal after appearantly exiting the process
• [ ] I replaced "nodeEnv === 'production' ? 'prod' : 'dev'," with "prod", as it was before and I don't know why it is was a mistake (?) but it solves this problem:

it produces the development build but it also starts it which seems wrong to me, although I put --noninteractive and when removing the --node-env=development it produces the production build without starting it

• [ ] I think I still have to make some sort of test for the improved --node-env option, am I right?

@fivethreeo Please let me know if you can help me with any of these tasks/questions listed above. Any feedback is appreciated. Thanks.

fonts included module.exports = __webpack_public_path__ + "link-to-media-fonts";

browser cannot parse it

how to fix ?

(media contains normal ttf font and etc types)

🚀 Feature request

I've been investigating the best way to add a middleware to my razzle server to detect whenever it serves a file built by razzle that includes a webpack [hash:8] or [contenthash:8] in the filename. I first discussed some of the problems I'm running into here https://github.com/jaredpalmer/razzle/pull/1368#issuecomment-664015050

I would like razzle to generate and expose the list of files/assets safe to be considered "immutable" (for the purposes of setting Cache-Control headers in responses) in a way that is easy to consume without extra transformation of the chunks.json and/or assets.json files

NOTE: when setting long-lived & immutable cache-control responses I want to avoid doing any kind of "approximation" on whether a file can be considered immutable (AKA regex to detect a hash in the filename) because a false positive can lead to a file being immutably cached for a long time and wouldn't be fixable by a server-side cache invalidation, which can be a very painful problem to work around.

Current Behavior

TL;DR of why trying to use the currently exposed json files is difficult:

• In order to get the concrete list of all files that are safe to cache immutably (because they have build or content hashes in them) I need to use both chunks.json and assets.json. chunks.json includes sourcemap files and assets.json has files like png/fonts etc which chunks.json doesn't.
• The assets.json and chunks.json aren't in the same format (this is possibly a problem that manifests for me because I let webpack split things across multiple chunks) so require different ad-hoc transforming to collate the complete list of all files/assets. Some of the differences are:
  • It seems for any chunk that isn't in (assets.json).client (eg: "client": { "js": "/static/js/bundle.6fc534aa.js" }), assets.json group all other assets under an empty string (eg: "": { "js": "/static/js/0.cb47cee9.chunk.js" }).
  • if only one file is present in a chunks.json group it will be an array with one item in it (eg: "client": { "css": ["filename.css"] }), if there's only one file file present in assets.json it will instead just be the single string (eg: "client": { "css": "filename.css" }).
• My assets.json currently contains "json": "/../chunks.json" which is not something that I think should be in there (i'm not sure if this is a bug or not) but I have to manually strip this out when making the list of files that can be given long lived cache-Control response headers.
• The plan to add a chunks: ["1", "2", "3"] array to the chunks.json is somewhat annoying because it means I have to do extra work to filter out the (chunks.json).client.chunks because it doesn't contain an array of files like (chunks.json).client.css and (chunks.json).client.js etc.
• Before the change I made here files not in the client chunk weren't even appearing in the chunks.json file. I made/suggested the change to change it to using the chunk number(s) as the key because at least they then appear in the file. The downside of this is that now chunks.json and assets.json diverse further in their schema when dealing with chunks that aren't the primary named chunk ("client": {/* blah */ }).

using assets.json and chunks.json

Currently using the assets.json and chunks.json this is what I've had to do roughly so far

I haven't:

• added loading the assets.json yet and resolving differences between the formats
• Filtering out files/fields in the json that I know aren't meant to be there like "chunks": ["1", "2", "3"] and "json": "/../chunks.json"

function razzleCacheableFiles() {
  // TODO: Add loading the assets.json file to support (png/txt files etc)

  // eslint-disable-next-line @typescript-eslint/no-non-null-assertion
  const chunks = require(process.env.RAZZLE_CHUNKS_MANIFEST!);
  const filesByType = Object.entries(chunks).reduce(
    (chunkAcc: any, [, chunk]) => {
      const types = Object.entries(chunk as any).reduce(
        (typeAcc, [fileType, files]) => {
          return {
            [fileType]: chunkAcc[fileType]
              ? [...chunkAcc[fileType], ...(files as string[])]
              : files,
          };
        },
        {},
      );
      return types;
    },
    {},
  );
  const files = Object.entries(filesByType).reduce(
    (acc: any[], [, files]) => [...acc, ...(files as string[])],
    [],
  );
  return files;
}

const cacheableFiles = razzleCacheableFiles();

// Serve static files located under `process.env.RAZZLE_PUBLIC_DIR`
const assetCaching = {
  immutable: {
    maxAge: CacheFor.OneMonth,
    sMaxAge: CacheFor.OneYear,
  },
  default: {
    maxAge: CacheFor.OneDay,
    sMaxAge: CacheFor.OneWeek,
  }
};
app.use(
  serve(process.env.RAZZLE_PUBLIC_DIR!, {
    setHeaders(res, path) {
      const filename = path.replace(process.env.RAZZLE_PUBLIC_DIR!, "");
      const hasHashInFilename = cacheableFiles.includes(filename);
      if (hasHashInFilename) {
        const { immutable } = assetCaching;
        res.setHeader(
          "Cache-Control",
          `max-age=${immutable.maxAge},s-maxage=${immutable.sMaxAge},immutable`,
        );
        return;
      }
      res.setHeader(
        "Cache-Control",
        `max-age=${assetCaching.default.maxAge},s-maxage=${asetCaching.default.sMaxAge}`,
      );
    },
  }),
);

Desired Behavior

There are would probably be many ways to do this but the primary thing I want is just a way to load an array of all cacheable/immutable assets generated by razzle build. the result could look something like this:

// File: caching.json
// contains all files/assets with a hash in them regardless of what type of file they are.
{
  "immutable": [
    "/static/js/0.cb47cee9.chunk.js",
    "/static/js/0.cb47cee9.chunk.js.map",
    "/static/js/0.cb47cee9.chunk.js.LICENSE.txt",
    "/static/media/ferris-error.407b714e.png"
  ],
  // I'm not even sure if this is required because I don't think razzle generates any files that don't have hashes in them?
  // possibly files copied in from the `public/` directory during build. but I'm not even sure if it'd that'd useful
  "standard": []
}

// RAZZLE_CACHING_MANIFEST is probably a silly name but 
const cacheableFiles = require(process.env.RAZZLE_CACHING_MANIFEST!);

// Serve static files located under `process.env.RAZZLE_PUBLIC_DIR`
const assetCaching = {
  immutable: {
    maxAge: CacheFor.OneMonth,
    sMaxAge: CacheFor.OneYear,
  },
  default: {
    maxAge: CacheFor.OneDay,
    sMaxAge: CacheFor.OneWeek,
  }
};
app.use(
  serve(process.env.RAZZLE_PUBLIC_DIR!, {
    setHeaders(res, path) {
      const filename = path.replace(process.env.RAZZLE_PUBLIC_DIR!, "");
      const hasHashInFilename = cacheableFiles.immutable.includes(filename);
      if (hasHashInFilename) {
        const { immutable } = assetCaching;
        res.setHeader(
          "Cache-Control",
          `max-age=${immutable.maxAge},s-maxage=${immutable.sMaxAge},immutable`,
        );
        return;
      }
      res.setHeader(
        "Cache-Control",
        `max-age=${assetCaching.default.maxAge},s-maxage=${asetCaching.default.sMaxAge}`,
      );
    },
  }),
);

Suggested Solution

I haven't fully investigated what a good solution would be but after trying to put together this list of "cacheable assets" at runtime using the assets.json and chunks.json I'm pretty convinced that at a minimum the best way to accomplish this would would be at build-time with some kind of webpack plugin and bypass the inconsistencies of those two files.

For my purposes I'll probably initially start looking into how to accomplish this with a plugin rather than with at runtime as i've been doing, but I think there'd be significant value to have this baked-in to razzle by default. Being able to set long-lived cache-control on hashed files is largely why they get hashed to begin with, so exposing a list of all those files seems appropriate.

Who does this impact? Who is this for?

Any users who want to set appropriate long-lived & immutable cache-control response headers for files generated & hashed by razzle.

Describe alternatives you've considered

• Generate list of all immutable/cacheable files at runtime by clobbering together chunks.json and assets.json (seems error prone and fragile).
• Create an external plugin to pre-generate list of cacheable files at buildtime. (seems possibly fragile across razzle versions for a feature that seems like it should be baked-in/stable)
• Add it as an internal plugin to razzle's default config and expose a way to access it by default eg: require(process.env.RAZZLE_CACHING_MANIFEST!). ()

Additional context

I'd be willing to help/contribute towards making this change but I might need a bit of a point in the right direction (and of course whether or not this is a change that would be accepted/welcomed).

Also a thought, having something like this might make it easier to have some tests/stability around ensuring that things are using [contenthash:8] instead of [hash:8] (build hash) if/when they can https://github.com/jaredpalmer/razzle/issues/1331

• [x] Upgrade Babel to v7, Jest to v23.6 #775
• [x] Remove default polyfills, direct people to use CRA's #788
• [x] Add treeshaking in production #780 @thelarkinn
• [ ] Optionally transpile node_modules with babel (like CRA does)
• [x] Remove eslint and make it a plugin

🚀 Feature request

Current Behavior

Hey team, I spotted some movement on the WP5 branch and wanted to request that your config setup is compatible with ModuleFederationPlugin.

Desired Behavior

Pretty much, depending on how exposed you allow your config - to check that it works with ModuleFederationPlugin, I’ve had some challenges with Next.js and upgrading them to webpack then on top of that provisioning support for the new feature in v5 core.

Typically, for simplicity - id have some flag that ensures runtimeChunk is not set to single if the user decides to use MF

Suggested Solution

Install the plugin and make sure options can be passed to the end user. Your project is along a similar thread to next (I think) and is leveraged for micro-frontend type builds. Stitching layers have always been a tricky issue.

Routing between apps requires reloading pages and so on, duplicate vendor code, or externals have typically been depended on but have limits and inflexible restraints.

At webpack We have been working pretty hard to resolve this. Essentially allowing users to import() code from independent applications that are deployed separately and run standalone. It works with anything webpack can process today. Also working in the node runtime, enabling ssr to be stitched at runtime and software to be evergreen if users decide to use that capabilities.

Who does this impact? Who is this for?

It’s quite a big impact to users. Especially ones with challenges around scale and autonomy.

The feature is being shipped in angular around September. Being built into storybook, and Microsoft is moving as well.

The current code in the branch looks pretty new and I cannot foresee any potential issue supporting it or documenting how to enable it within your platform.

The implementation is very straightforward. Takes about 5 min to setup from scratch. And requires no syntactic or structural changes to user codebases. They simply use import and the parser will handle federated code accordingly by leveraging new module factories we designed in the core.

Describe alternatives you've considered

Honestly there’s not been an alternative to try. Which is why we made some major modifications to webpack core. I guess dll plugin is a rudimentary and context bound concept. But even so it’s at build time and quite static. Doesn’t really solve modern problems in distributed systems.

Additional context

I’m the creator of ModuleFederationPlugin, working very close with Tobias as we prepare beta.17 to enable more advanced implementations. If you’re considering using or supporting it - I should be able to answer any questions.

I’ve also got a decent number of resources, videos, articles and so on under the Federation organization https://github.com/module-federation/module-federation-examples

Let me know if I can provide any additional information!

start.js:

• Close server watcher on SIGINT/SIGTERM.

StartServerPlugin.js:

• On SIGINT, if the child process SIGINT handler is not in place yet or 5 seconds have elapsed, exit right away.
• On non-SIGTERM signals, if the child process SIGINT handler is in place, exit once the child process has exited. This allows the (http) server to go through its SIGINT shutdown sequence if any.

The devDependency lerna was updated from 2.10.1 to 3.9.0.

This version is not covered by your current version range.

If you don’t accept this pull request, your project will work just like it did before. However, you might be missing out on a bunch of new features, fixes and/or performance improvements from the dependency update.

Find out more about this release.

Your Greenkeeper bot :palm_tree:

I have noticed a few miscellaneous issues with razzle. I'm not sure how to best report them, so I opened this bug report.

1. When using verbose, webpack-dev-server displays this message where the from is always 'undefined'.

ℹ ｢wds｣: webpack output is served from undefined

2. When I was compiled my project at first, razzle said the client was compiled with errors but never displayed what the errors were. It would process to compile the server and also reported errors there without displayed them either. An error would usually show up at runtime later on. It would be great if compile errors could be reported.

3. The console message output of razzle is displayed with colors. Yet the colors from the server console messages are removed when messages are displayed. I use the 'debug' npm package and colors are very useful when debugging.

Semi-related, when the server (or proxy if any) are issuing messages, the client compile looks like this:

● Client █████████████████████████ building (69%) 1237/1254 modules 17 active

● Client █████████████████████████ building (69%) 1258/1271 modules 13 active

● Client █████████████████████████ building (68%) 1281/1314 modules 33 active

● Client █████████████████████████ building (68%) 1300/1327 modules 27 active

Not sure there is an easy to deal with that without some complex terminal split view.

4. I had an instance when one of the servers was still running after pressing ^C to interrupt and I had to kill the process manually.

type: bug report. browsers: chrome and firefox latest port: default port 3000 report: Hot module reload says its working to be working but i have to hit page refresh to see the update. Please note the site is running behind a nginx proxy but this hasnt affected other react and next apps running ok on different ports.

here is the server log on saving a change to a file.... looks like its working.

1|razzle | ℹ Compiling Client 1|razzle | ℹ Compiling Server 1|razzle | ✔ Server: Compiled successfully in 389.42ms 1|razzle | ✔ Client: Compiled successfully in 413.53ms 1|razzle | ℹ Compiling Client 1|razzle | 🔁 HMR Reloading ./server... 1|razzle | [HMR] Updated modules: 1|razzle | [HMR] - ./src/Home.js 1|razzle | [HMR] - ./src/App.js 1|razzle | [HMR] - ./src/server.js 1|razzle | [HMR] Update applied. 1|razzle | ✔ Client: Compiled successfully in 526.55ms

thanks