Support Deno

[valtlai]

It would be now easy to publish a Deno version of this package.

After (and if) this PR is merged:

1. Make sure the missing tag for 7.0.1 is created, if intended, because it can’t be done later, so that this version is not published for Deno.
2. Register a webhook. See the instructions by clicking the Publish a module button on deno.land/x.
3. Publish the initial version for Deno by creating a new version tag.

[jonathantneal]

Hey @valtlai, thanks for putting this together. I want to understand what this is doing a little better, so that I can support it, and so that I don’t break it for future users.

In this PR, can you tell me more about why you’ve directed the mod.js file to direct folks to the source index? Could the src/index.js file be used itself?

[valtlai]

Using mod.js is just a convention in Deno, so that the import URL is like https://deno.land/x/module_name/mod.js. Deno doesn’t support implicit index files, so https://deno.land/x/postcss_nesting/src/ won’t work and you have to use https://deno.land/x/postcss_nesting/src/index.js. The name index.js is avoided, because it has no special meaning in Deno and the name is therefore a bit confusing.

I added a comment to the mod.js file about that it’s an entry point for Deno.

[valtlai]

Updated ./src/index.js to ./src/postcss-8-nesting.js.

[jonathantneal]

Is there a way to support Deno without adopting the mod.js file? May we point the repository to postcss-nesting.js and skip the mod.js file? Or would it help if I moved the postcss-nesting.js file into the root directory of the project, since the intention is to run this file on its own in deno land?

Now, I also have some critique here, but it’s not of you. You’re only being helpful. You’ve done absolutely nothing wrong! It is this manual that seems problematic to me. From the manual:

If a directory of code needs a default entry point, use the filename mod.ts.

Critique directed at the manual: Does this project need a default entry point? It has a file named postcss-nesting.js.

The filename mod.ts follows Rust’s convention, is shorter than index.ts, and doesn’t come with any preconceived notions about how it might work.

Critique directed at the manual: I follow conventions because they communicate meaning thru preconceived notions. For example, I might name a file mod because it relies on authors’ preconceived notions of how this file name works in Rust, specifically to communicate that the file is a default entry point. Only, doesn’t that defeat the intended purpose of dropping preconceived notions? And isn’t it worse to suggest a new preconceived notion when the premise is that index already carries such preconceived notions? If this argument hinges on the number of characters, I guess I need some proof that developers had longed for a default entry point shorter by 2 characters.

index vs mod

[jonathantneal]

Again, you’ve done me a great service. I’m committed to merging something, in order to support Deno users and to respect your time. I don’t want my critique of this convention to come across in any way as a critique of generous help.

I’m also ready to be proven so super duper wrong by the Deno manual. I’m wrong all the time. 😄 I’d like to learn and grow more than stay wrong.

[valtlai]

Is there a way to support Deno without adopting the mod.js file?

If we skip the mod.js file, one could import the plugin in Deno with:

import postcssNesting from "https://deno.land/x/postcss_nesting/src/postcss-8-nesting.js";

So the URL is just a bit longer and discontinuous because it mixes underscores and hyphens, but I think we can live with it.

May we point the repository to postcss-nesting.js

There’s no way to point deno.land/x to a specific file but a specific directory. If we did that for src, the import would look like:

import postcssNesting from "https://deno.land/x/postcss_nesting/postcss-8-nesting.js";

So we would only save four characters (/src) and the deno.land/x page for the module won’t show README.md because it’s outside the src directory.

Or would it help if I moved the postcss-nesting.js file into the root directory of the project

This way we can avoid the missing readme file, but we still only save four characters. An alternative approach would be to add a second readme file to the directory that deno.land/x uses.

---

So maybe we just delete mod.js and update the installation docs to use the URL https://deno.land/x/postcss_nesting/src/postcss-8-nesting.js.

[jonathantneal]

That’s really helpful to know how this impacts the README.md.

Let me know if you’d be okay with me moving the source into the root directory. I’ll even try to give it a name free of hyphens, and I’m open to your suggestions.

https://deno.land/x/postcss_nesting/nesting.js

https://deno.land/x/postcss_nesting/postcss_7_nesting.js # for PostCSS 7

If you think this is a helpful resolution, I would like to merge your PR, at whatever stage you want it merged, and then I can commit the additional changes needed, and then validate those changes with you before I release v8.0.2.

Let the know. Thank you, again!

[valtlai]

PostCSS 7 isn’t available for Deno, so we only need the PostCSS 8 version (https://deno.land/x/postcss_nesting/nesting.js in the comment adove).

[oscarotero]

Hi. Thanks for give support for Deno to this plugin!

Just to clarify the mod vs index. The use of index.js in node is inspired from the web servers, that use the index.html file as default when the request is pointing to a directory. So the preconceived notions of index.js is that if you import the directory name, you're importing the index.js file.

In node you don't even need the extension because the file system is fast enough to check if the module path is a directory with an index.js or a file without extension.

In the browser, we don't have a file system to make these checks, so this is why the modules in javascript are explicit (including the filename and the extension). Deno works like the browser in this aspect, using ESM and removing all "magic" and complexity of CJS in order to have a more explicit and clear module system.

So the reason to discourage the use of index.js / index.ts files is because you can think that importing the directory url is the same than importing directly the index.js file. Sometimes, your library has a unique entry point, so they decided to use the mod.js as a convention for that, inspired in rust, but they could use any other name like main.js, entry.js etc. The important thing is that any other name different to index.js doesn't have the preconceived notion of automatic loaded, like in a web server.

Ryan Dahl explains it better here: 10 Things I Regret About Node.js (point 7)

That said, it's not required to have a mod.js, and index.js or any other filename works too, because we only need the url of an existing javascript file.