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

ctr-loader

v0.2.1

Published

ctr loader module for webpack

Downloads

3

Readme

ctr-loader

npm npm wercker status David

Description

An unopinionated-ish loader specifically designed to work hand-in-hand with ctr and its Javascript API. The loader itself is pretty damn simple, and the heavy lifting is done through the ctr Javascript API. Nevertheless, without working knowledge of both ctr and it's complementary Javascript API this loader will be of little use.

Documentation

The documentation is on docs.ctr-lang.com because I can control the format and presentation. The following links correspond to the various parts of the documentation.

The Gist

module.exports = {
  // ...
  module: {
    rules: [{
      test: /\.ctr(\.js|\.yml|\.yaml)$/,
      use: ['style-loader', 'css-loader', 'ctr-loader']
    }]
  }
  // ...
};

Test's

I love tests, and I try to treat every test like a mini-demo or an example in and of itself. Accordingly, the tests not only validate the raw mechanics of Webpack but also to give a better understanding of the modes of action ctr can facilitate. In fact, I would go as far as to say the tests focus more on the mode of action compared to the Webpack mechanics, although, you can't have one without the other. I highly encourage you to cruise on over to /__tests__ because I can only convey limited context through wordz.

Thoughts on Naming Conventions

I'm a big fan of the [filename].ctr.js and [filename].ctr.yml file extension naming convention for a few reasons, but primarily because it eliminates potential ambiguities. However, this naming convention by no means is mandatory, and you can use any test Regex you desire for the loader.

In the tests, for the main ctr entry point, I employ the naming convention of _index.ctr.js. My thinking behind this convention is it ensures the entry file is always at the top of the folder directory. Nonetheless, I should note, this convention could confuse other developers since the underscore typically signals a private meaning of sorts.

Individual ctr styles, depending on size and grouping should be in split into separate files when it makes sense. Then if possible the file names should correspond to the styles selector, i.e. box.ctr.js, nav.ctr.js. This naming convention builds upon the .ctr.js filename extension convention to quickly allow you to navigate to specific style files though a fuzzy file search.

Thoughts on Structure

My current thoughts regarding a pure Javascript ctr structure is quite malleable, but in my opinion, you should focus your project around single entry points. That is, for a component style, depending on size, I would break the ctr file down into corresponding style elements and have a single entry point in which you coalesce those styles via requireWatch. At the same time, writing ctr styles in Javascript is a pain in the butt, and you should consider a structure that favors the YAML flavor of ctr.

Generally speaking, I recommend you utilize CSS preprocessor architectures like ITCSS. There's no reason to reinvent the wheel even if you're trendy cat CSS'ing in JS. In relative terms, requireWatch is the same thing as a CSS preprocessor's @import. Also, keep in mind, requireWatch can accept an Array of file paths, so you don't have to wear out your little weary fingers by having to type requireWatch a billion times like you have to do with @import.

In terms of ctr classes, you should and can leverage them. As I mention in the documentation, don't rely on webpack's loading order of require. One would think you could, or at least I did at one point, however, during production builds specifically about ~8% of the time things get fucked in more or less words. As far as I can ascertain the fault lies in ctr but as to why I'm not all to sure, and I can only assume it's a combination of factors like the weather. In retrospect, regardless of this bug/error, I believe this implicit structure is by it's nature an anti-pattern. Rather I suggest you use a declarative approach when it comes to classes in which you use requireWatch at the head of a style. This not only solves the build bug/error, but more importantly it indicates to other developers that you're using classes and the location of said classes.

Webpack 1.x.x Tests?

Sorry, don't got the time to spin up all those rhymes.


Best, te