google / postcss-rename Goto Github PK

https://evilmartians.com/chronicles/postcss-8-plugin-migration

Hi,

I am trying this postcss plugin with tailwind and I found that postcss-rename are broken some properties. I have a reproduction in this repo: https://github.com/RodrigoTomeES/awa-db/tree/feature/optimize-classes

To test it you only need:

yarn install
yarn build

In ./dist/_astro/ folder you can found the CSS file and in the root of the project should be has the file with the map.

You should see things like this:

@media (min-width: 768px) {
  .ub {
    t-template-columns: repeat(3, minmax(0, 1fr));
  }
  .vb {
    font-size: 3rem;
    line-height: 1.625;
  }
}

.O {
  s-radius: 0.35rem;
}

Currently the continuous integration only runs blaze test //..., which doesn't run the Jest tests.

We should add Jest to CI, as separate CI command(s) to run and/or as extra Bazel test target(s).

Hi, think I have a somewhat unusual use case in that I've written a small CLI to convert CSS modules into BEM (so users of a library can have a choice). It's working pretty well, except I still need it to transform some CSS module specific :global(.selector) pseudo elements which aren't legal in regular CSS.

So far the relevant part of the code is like this:

const camelToKebab = (str) =>
  str.replace(/([a-z0-9])([A-Z])/g, '$1-$2').toLowerCase();

const strategy = (selector) => {
  return `${camelToKebab(selector)}`;
};

async function main() {
  return await postcss([
    renamer({
      strategy,
      ids: true,
      prefix: `${prefix}${componentName}__`,
    }),
  ]).process(cssFile, { from: undefined });
}

main().then((o) => {
  fs.writeFileSync(newPath, o.css);
});

This works very well, unless the file contains any :global. Initially, I tried to add a regex in the strategy function, but noticed it doesn't receive the relevant pieces.

const strategy = (selector) => {
  const convertedCase =`${camelToKebab(selector)}`;

  // transform :global(.selector) to .selector
 return convertedCase.replace(/:global\((.+)\)/gm, ' $1');
};

Probably will just handle it manually if it can't be done and isn't worth adding as a feature.

We're currently using a custom CommonJS wrapper and ambient typings for the guava-js bower package. The wrapper is a series of eval("[...]/node_modules/guava-js/[...].js") statements(!).

It'd be nice to either remove or replace this dependency, obsoleting this issue, or switch to an npm-published version of guava-js that can be loaded like any other regular Node.js module.

I've always wished Closure Stylesheets would have such a feature – it could rename css variables and emit it in a call goog.setCssNameMapping just like other class names, so that one can modify its value in JS via something like element.style.setProperty(goog.getCssName("--my-variable"), "#fff"). Would such a feature be in the scope of this project?

We're currently using ambient typings for the conditional npm package.

It'd be nice to have typings for these and upstream them, either to conditional itself or to DefinitelyTyped, rather than having our own local typings.

Hi,

I am currently working on implementing an integration of this package for Astro. I have noticed that the plugin loses the context of the previous CSS Class Map. This issue arises when there are multiple CSS files, as it can lead to errors with duplicate keys for different classes when iterating through minified classes.

I wanted to inquire if there are any plans to modify this behavior. Currently, I have a version that supports only one CSS file, but I would like to make it compatible with multiple CSS files. This would involve ensuring that the context of the previous keys is maintained while iterating through the minified classes.

Thank you.

Please add an example to the readme

Currently, all the built-in renaming types other than NONE do "by-part renaming": they rename each hyphenated component of a class name individually (as opposed to "by-whole renaming", which renames the entire class). Rather than baking this in to particular renaming types, I think we should have a byPart: boolean configuration option for it that's orthogonal to the renaming type.

I also think this option should default to false. While by-part renaming is common within Google, it generally produces more bytes of output for relatively little value for new users. I think most people would prefer by-whole renaming.

This currently mangles @keyframes breakpoints that contain decimal points. For example, with strategy: "debug", it converts:

@keyframes name {
  0.1% {opacity: 0.1}
}

into

@keyframes name {
  0.\31\%_ {opacity: 0.1}
}

As in the title. :)

Thanks.

Currently, the class renamer only supports its own built-in renaming logic. It should also support passing in a custom string -> string function that can rewrite names based on user-provided logic.

I wanted to use this plugin with NextJS and tailwind, but there seems to be no guide on how to use it at all. Is there any tutorial I can follow?

Currently this package only supports renaming classes, but some of our users have requested the ability to rename IDs as well. I suggest adding an ids: boolean | Partial<Options> field, where true indicates that IDs should be renamed using the same logic as classes and Options allows ID renaming to be configured differently than class renaming.

Currently the continuous integration only runs blaze test //..., which doesn't run any lints.

We should add lints to CI, as separate CI command(s) to run and/or as extra Bazel test target(s).

When a JS node module consumer uses a TS node module that exports using export default, the JS author must write const moduleName = require('module-name').default.

This is unnatural for node modules, so we should switch the default export to export =, as per https://www.typescriptlang.org/docs/handbook/modules.html#export--and-import--require.

Note this means we can only have one export per file, i.e. we can't export the Options interface simultaneously.

I think this export is unnecessary, given the interface is only for type hinting to users of the plugin. This would break in the case a user wants to wrap the plugin with TS and forward the Options type explicitly, so we may want to consider making the Options interface available in a standalone options.ts file.

Until that's required, I think we can keep Options unexported.

This project has used google/gts to bootstrap, which as of google/gts@b3096fb has switched to eslint.

We should follow suit.

Hello!

I'm excited to introduce you to the plugin astro-rename. It seamlessly integrates with Astro, eliminating the need for additional configuration.

I have ambitious plans to enhance the plugin by incorporating more options and decoupling its logic, allowing it to be used with builders such as Vite, Webpack, and Rollup.

Any contributions are highly appreciated, so please feel free to submit pull requests.