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 🙏

© 2026 – Pkg Stats / Ryan Hefner

comment-loader

v0.0.4

Published

A wepback loader using comment to do precompilation work.

Readme

comment-loader

A wepback loader using comment to do precompilation work.

###Install npm install --save-dev comment-loader

###Why we need it? Conditional code is not allowed in ES6+, this means you cannot use if-else or switch-case structure to enable/disable some modules. However if some precompilation work can be performed before webpack pass your code to babel or other ES transformers, the problem can be solved easily. Macro like C-style macro can be a way to do all this.

###What different? Some Macro loaders can already be found on github or npm. However, they usually cause some side-effects. Using Macro directly will break the syntax which will cause big problem if the loader is not available.

Here I use the hack on comments and babylon parser to detect the define Macro. Using comments is a way to lower the side-effects as many as possible, though it still bother IDE sometimes. Comments are not force to be at the beginning of the line, since babylon can always detect AST correctly. Another important reason why I use babylon is that I hope the comments can do more in future. Maybe I'll let loader support simple if-else or switch-case structures in comments with some defined patterns.

###When to use it? Here is an example of developing app with redux.

import {createStore, compose} from 'redux';
import rootReducer from '../reducers';
import {persistState} from 'redux-devtools';
import DevTools from '../containers/DevTools';

const enhancer = compose(
    DevTools.instrument(),
    persistState(
        window.location.href.match(
            /[?&]debug_session=([^&#]+)\b/
        )
    )
);

export default function configureStore(initialState) {

    return createStore(rootReducer, initialState, process.env.NODE_ENV === 'production' ? undefined : enhancer);

}

redux-devtools is very useful when developing apps, however it only use WebpackDefine plugin can have great problem when build bundles.WebpackDefine works after babel-loaderbut before uglify which means the modules are already bundled together before the WebpackDefine plugin works.

This problem in this issue is almost the same. The tree shaking won't work because building modules is performed before removing dead code. Webpack can mark unused imports/exports, maybe this is also possible for the issue by some ways like simply marking the statements and specifiers. But in my case, I think it is impossible. If an analyzer can tell enhancer is no longer used when process.env.NODE_ENV === 'production', and it cannot tell whether compose use it or not. If recursive detection can be performed, it must be a time consuming work.

I now think these kind of use WebpackDefine plugin is a mistake, especially when the variables defined are related to the module dependency. So I don't think Webpack should focus on this kind of problem.

This loader allows you to write code like below:

import {createStore, compose} from 'redux';
import rootReducer from '../reducers';

//<#IF_DEF DEBUG>
import {persistState} from 'redux-devtools';
import DevTools from '../containers/DevTools';

const enhancer = compose(
    DevTools.instrument(),
    persistState(
        window.location.href.match(
            /[?&]debug_session=([^&#]+)\b/
        )
    )
);

//<#END_IF>


export default function configureStore(initialState) {

    let store;

    //<#IF_DEF DEBUG>

    store = createStore(rootReducer, initialState, enhancer);

    //<#ELSE>

    store = createStore(rootReducer, initialState);

    //<#END_IF>
    return store;

}

The <#IF_DEF DEBUG> , <#ELSE> and <#END_IF> are all needed.

###How to use? Webpack config file.

module: {
        rules: [
            {
                test: /\.js$/,
                include: [
                    path.resolve(__dirname, '../src')
                ],
                exclude: [
                    path.resolve(__dirname, '../node_modules')
                ],
                use: [
                    {
                        loader: 'babel-loader'
                    },
                    {
                        loader: 'comment-loader',
                        options: {
                            definition: ['DEBUG']//['RELEASE']
                        }
                    },
                ]
            }
        ]
}

Note: You should always put comment-loader on the right of babel-loader or other loaders. babel-loader will mess up the comments between import lines thus making macros invalid.