npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

replace-resolve-webpack-plugin

v0.0.7

Published

Allows replacement of imports based on equivalent relative path in a given directory

Downloads

27

Readme

replace-resolve-webpack-plugin

NPM version release build XO code style

This is a webpack resolve plugin which supports replacing imports in directory A, with any imports that exist at the same relative path in directory B (optional substitution by convention).

There are potentially a few scenarios where this might be useful to do at build-time, some which spring to mind are...

  • Creating variations of a bundle (branding/experimentation/compile-time feature flags)
  • Replacing modules for use in storybook, which also uses webpack at the time of writing, without the overhead of a mocking framework.
  • Tailoring libraries for multiple targets using the same source (react native maybe?)

While it makes sense in situations where you want to replace a lot of imports with different values, it's less convenient in cases where the intention is to redirect lots of modules to a small set of replacements; in such cases I would suggest leveraging either webpack's alias or NormalModuleReplacementPlugin.

Alternatively, in simple use cases where only module resolution precedence (no absolute, dot paths or imports with extensions are involved), it would probably be simpler to make use of resolve.modules in webpack's configuration rather than using this plugin.

For example, the equivalent to the plugin example would look like this:

import { resolve } from "node:path";

/** @type {import("webpack").Configuration} */
export default {
    // ...
    resolve: {
        modules: [
            resolve("./replacements"), 
            resolve("./src"),
            "node_modules",
        ],
    },
};
// results in ...
import Foo from "components/Foo" 
// resolution attempts in order:
//    1 ./replacements/Foo
//    2 ./src/Foo 
//    3 **/node_modules/components/Foo

Example usage

import ReplaceResolvePlugin from "replace-resolve-webpack-plugin";
import { resolve } from "node:path";

/** @type {import("webpack").Configuration} */
export default {
    // ...
    resolve: {
        plugins: [
            new ReplaceResolvePlugin({
                from: resolve("./src"),
                to: resolve("./replacements"),
            }),
            `...`,
        ],
    },
};

Given the config above, any supported import may be replaced with a compatible substitute at the same relative path under ./replacements as the item to replace is at under ./src.

The same rules apply as with importing from the original, with mainFiles and extensions being applied from configuration, and other file types requiring an extension.

If a replacement does not exist, the original is preserved.

from and to must be absolute paths, but as far as I know they can exist anywhere (they can be outside of the consuming repository for example); that said, certain loaders may require the path to be included.