Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow modules and other attributes in script tags when copied #14038

Open
Explosion-Scratch opened this issue Apr 4, 2021 · 7 comments
Open

Comments

@Explosion-Scratch
Copy link

Explosion-Scratch commented Apr 4, 2021

If someone wants to put a module on CDNJS, then currently when clicking "Copy script tag" it turns out something like this:

<script src="https://cdnjs_url_here"></script>

what if in the json files describing the file, we could also add other attributes, e.g.

//Other JSON stuff here
"filemap": [
  {
      //I forgot how the proper way is to add files to CDNJS that should be tracked, sorry!
      // normal stuff here, like file location and stuff
      "attributes": {
            "type": "module",
            "async": "true",
            "defer": "true",
      }
  }
]
//More JSON stuff

Now clicking "copy script tag" would do this for the file in question:

<script src="https://cdnjs_url_here" async defer type="module"></script>

(oh, and of course only certain attributes would be whitelisted, so that people can't do onerror, or onload)

@MattIPv4
Copy link
Member

MattIPv4 commented Apr 5, 2021

👋 I like the idea and think it makes sense, however, yes, there would most definitely need to be an allowlist for both which attributes we allow and the values we allow for them.

An example package config might look something like this on cdnjs, currently:

{
  "name": "a-happy-tyler",
  "description": "Tyler is happy. Be like Tyler.",
  "keywords": [
    "tyler",
    "happy"
  ],
  "license": "MIT",
  "repository": {
    "type": "git",
    "url": "git://github.com/tc80/a-happy-tyler.git"
  },
  "filename": "happy.js",
  "autoupdate": {
    "source": "git",
    "target": "git://github.com/tc80/a-happy-tyler.git",
    "fileMap": [
      {
        "basePath": "src",
        "files": [
          "*"
        ]
      }
    ]
  },
  "authors": [
    {
      "name": "Tyler Caslin",
      "email": "tylercaslin47@gmail.com"
    }
  ]
}

I don't think it'd make sense for this data to live inside the fileMap property as it doesn't inherently need to be tied to the auto-update mechanism -- although we no longer permit it, a library can not have an auto-update config and it makes sense for it to still be able to set attributes on files it has (that've been manually added).

To me, it'd make sense to have it be a top-level structure in the JSON that defines attributes for specific files (or globs):

{
  "name": "a-happy-tyler",
  "description": "Tyler is happy. Be like Tyler.",
  "keywords": [
    "tyler",
    "happy"
  ],
  "license": "MIT",
  "repository": {
    "type": "git",
    "url": "git://github.com/tc80/a-happy-tyler.git"
  },
  "filename": "happy.js",
  "autoupdate": {
    "source": "git",
    "target": "git://github.com/tc80/a-happy-tyler.git",
    "fileMap": [
      {
        "basePath": "src",
        "files": [
          "*"
        ]
      }
    ]
  },
  "attributes": [
    {
      "file": "test.js",
      "attrs": {
        "defer": true
      }
    },
    {
      "file": "*.@(module.js|mjs)",
      "attrs": {
        "type": "module"
      }
    }
  ],
  "authors": [
    {
      "name": "Tyler Caslin",
      "email": "tylercaslin47@gmail.com"
    }
  ]
}

We would also want to have an allowlist of extensions that must be at the end of the file property (directly, or via any glob being resolved), only permitting perhaps js, cjs & mjs.

What do you think of that?

cc @xtuc @tc80 curious what y'all also think of this?

@Explosion-Scratch
Copy link
Author

I don't think it'd make sense for this data to live inside the fileMap property as it doesn't inherently need to be tied to the auto-update mechanism -- although we no longer permit it, a library can not have an auto-update config and it makes sense for it to still be able to set attributes on files it has (that've been manually added).

I like the idea of an attributes property in the JSON file as well as the ability to use regexes, I think that modules are a helpful tool for JavaScript developers, especially with the advantages that come with only importing specific items from them. As for other attributes here are the ones that I think should be allowable:

defer: This is really useful to make pages load faster.
async: Easily workaroundable from whomever is writing the script in the first place, but still nice to include.
type: For use with modules, not sure what other use the type attribute would have, considering that CDNJS already sets the correct headers when serving files.
nomodule: Important for supporting older browsers

All of the other attributes are for what information to send to the server, such as integrity and referrerpolicy. Also as a side note does CDNJS support ?callback=functionNameHere?

@Explosion-Scratch
Copy link
Author

Whoops, I clicked "Close with comment" 😐

@MattIPv4
Copy link
Member

MattIPv4 commented Apr 6, 2021

👍 Those four attributes make sense to me for now -- the first step in making this reality will be to create a PR that updates https://github.com/cdnjs/tools/blob/master/schema_human.json and https://github.com/cdnjs/tools/blob/master/schema_non_human.json to include the schema for the new attributes property :)


All of the other attributes are for what information to send to the server, such as integrity and referrerpolicy.

We already set integrity and wouldn't want uses to be changing that -- they can set referrerpolicy or anything else themselves after they've copied for now.

Also as a side note does CDNJS support ?callback=functionNameHere?

No -- we do not and will not ever support modifying the response sent back for an asset as this would invalidate the SRI hash that we inject.

@Explosion-Scratch
Copy link
Author

👍 Those four attributes make sense to me for now -- the first step in making this reality will be to create a PR that updates https://github.com/cdnjs/tools/blob/master/schema_human.json and https://github.com/cdnjs/tools/blob/master/schema_non_human.json to include the schema for the new attributes property :)

Sounds good!

All of the other attributes are for what information to send to the server, such as integrity and referrerpolicy.

We already set integrity and wouldn't want uses to be changing that -- they can set referrerpolicy or anything else themselves after they've copied for now.

But is there any use setting referrerpolicy? Does CDNJS do anything with referrer?

Also as a side note does CDNJS support ?callback=functionNameHere?

No -- we do not and will not ever support modifying the response sent back for an asset as this would invalidate the SRI hash that we inject.

Oh cool! I didn't know!

@MattIPv4
Copy link
Member

Does CDNJS do anything with referrer?

We don't do anything with it :)

@Explosion-Scratch Explosion-Scratch changed the title Allow modules in script tags copied Allow modules and other attributes in script tags when copied Jun 30, 2021
@MattIPv4
Copy link
Member

cc cdnjs/packages#1776

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants