| 00:23 | <bradleymeck> | devsnek: I think they do not currently inhibit the ability for a host to do application/package level configuration so I have no objections |
| 00:24 | <bradleymeck> | I think we should be careful about what we consider problematic and allow things even if only a specific subset of hosts would use them realistically |
| 00:26 | <bradleymeck> | I do think there will be synchronization / verbosity problems if we don't limit them to some central coordination system; but, for me just a simple registry like the MIME registry would be more than enough |
| 00:26 | <devsnek> | bradleymeck: they seem like a massive footgun |
| 00:26 | <devsnek> | and nothing else |
| 00:27 | <devsnek> | all the examples are specifying details about the module |
| 00:27 | <devsnek> | not the import |
| 00:33 | <bradleymeck> | devsnek: in the readme yea, but i don't see how that prevents other mechanisms like you described or conflicts with them |
| 00:34 | <bradleymeck> | to me the real conflicts come from things like customized revivers, which might need to be categorized differently |
| 00:39 | <devsnek> | this seems useful for whatever query parameters are used for |
| 00:39 | <devsnek> | and nothing else |
| 00:40 | <devsnek> | honestly that's not a bad test |
| 00:40 | <bradleymeck> | ? |
| 00:41 | <bradleymeck> | how do you assert the MIME via query params? |
| 00:41 | <bradleymeck> | thats controlled via the server not the client |
| 00:41 | <bradleymeck> | this lets the client add an assert |
| 00:41 | <devsnek> | exactly |
| 00:41 | <bradleymeck> | ? |
| 00:41 | <devsnek> | if you wouldn't put it in a query parameter |
| 00:41 | <devsnek> | you shouldn't put it in an attribute |
| 00:42 | <bradleymeck> | i don't understand, attributes are client local / not synced with the server |
| 00:42 | <bradleymeck> | the whole point is they aren't the same |
| 00:43 | <bradleymeck> | its adding an integration point that doesn't exist currently for source on the client to apply some kind of data to be used locally only |
| 00:43 | <bradleymeck> | query params are for integrating with the fetch/remote |
| 00:44 | bradleymeck | grumbles about this not being technically true in node |
| 00:50 | <devsnek> | bradleymeck: basically nothing specific to a module should be in an attribute |
| 00:51 | <bradleymeck> | I just don't see an answer to why thats the case |
| 00:51 | <devsnek> | type is project wide |
| 00:51 | <devsnek> | hash is project wide |
| 00:51 | <devsnek> | mocking is project wide |
| 00:51 | <devsnek> | I honestly have no idea what you would put in an attribute |
| 00:51 | <bradleymeck> | mocking is definitely project wide and gets replaced multiple times in test suites |
| 00:52 | <bradleymeck> | type can be defined project wide, but isn't necessarily only able to be defined there |
| 00:52 | <bradleymeck> | hash is the same, except for cycles |
| 00:52 | <devsnek> | yeah but anywhere else is a footgun |
| 00:52 | <bradleymeck> | devsnek: why? |
| 00:52 | <devsnek> | don't specify type somewhere and your code doesn't run |
| 00:52 | <devsnek> | very good experience |
| 00:53 | <devsnek> | forget to specify hash somewhere and maybe you have a security problem |
| 00:54 | <bradleymeck> | devsnek: those are host level concerns though |
| 00:54 | <bradleymeck> | i doubt node would enforce the need for a type attribute / I wouldn't want them to |
| 00:54 | <bradleymeck> | but if one is supplied, it does the check |
| 00:55 | <devsnek> | if the best that can be said is "people won't use it anyway" |
| 00:55 | <devsnek> | why bother adding it |
| 00:55 | <bradleymeck> | i don't see how thats a net negative, its just another layer of ways to verify things |
| 00:55 | <bradleymeck> | people will use it / linters may add it, but it being *Required* is up to the host |
| 00:56 | <devsnek> | it seems to be completely net negative to me |
| 00:56 | <bradleymeck> | how so? it adds a way for people to opt-in to a form of verification they cannot currently do |
| 00:56 | <bradleymeck> | that doesn't seem to take away anything |
| 00:58 | <devsnek> | I mean people can't call numbers either |
| 00:58 | <devsnek> | that doesn't mean we need to add it |
| 00:59 | <devsnek> | any time you would want to use this it seems like the actual correct thing would be a project wide config |
| 00:59 | <devsnek> | maybe if your app is a single file this makes sense |
| 01:00 | <devsnek> | but like... |
| 01:00 | <devsnek> | idk even then |
| 01:00 | <bradleymeck> | [[Call]] on numbers doesn't verify things / idk how that relates |
| 01:01 | <bradleymeck> | this actively does something that might be appealing. the ability to make assertions about what type is being evaluated when loading a module |
| 01:01 | <devsnek> | bradleymeck: I think it's inherently incorrect for that assertion to occur at the import site |
| 01:02 | <bradleymeck> | honestly node's policy mechanism might be aided by a similar constraint so that you could state a app can load arbitrary files, but only JSON |
| 01:02 | <devsnek> | that assertion should be specified somewhere that blankets all import sites |
| 01:02 | <bradleymeck> | devsnek: I think there isn't a real reason that having it at the import site is shown to be problematic so far |
| 01:02 | <bradleymeck> | i don't disagree, but i don't see how at import site is harmful |
| 01:04 | <bradleymeck> | just because there are multiple ways of doing something doesn't mean we can/should define 1 way as the only way. I don't see a direct conflict of these assertions, if you have conflicts of import site and app config it just means it 100% will fail to load |
| 01:04 | <bradleymeck> | which seems correct |
| 01:05 | <bradleymeck> | it would be good to see how having it at an import site does cause problems. omission is the current state and most people agree that having no mechanism for these asserts isn't a great path forward |
| 01:07 | <bradleymeck> | having an out of band mechanism doesn't seem to have any clear problems co-existing with an in band mechanism so far |
| 01:08 | <devsnek> | why are we making something where you can do it incorrectly |
| 01:08 | <devsnek> | is my question |
| 01:09 | <devsnek> | obviously type fails loudly but not everything does |
| 01:10 | <devsnek> | for example missing a hash at an import |
| 01:11 | <bradleymeck> | because convenience and UX. even with app configuration you could do it wrong there |
| 01:11 | <devsnek> | it's just weird to me that people want to specify things inherently bound to the module in the completely wrong place |
| 01:12 | <devsnek> | idk I think it's better UX to not let people make these mistakes |
| 01:12 | <bradleymeck> | to be fair, doing it all in 1 place like node policies does slow down boot time |
| 01:12 | <devsnek> | the entire premise is that not having this info is bad |
| 01:12 | <bradleymeck> | it isn't like thats a wonderful solution either |
| 01:12 | <devsnek> | so let's reduce the places where you can be missing this info |
| 01:13 | <devsnek> | you mean loading the policy file takes time right? |
| 01:15 | <bradleymeck> | devsnek: loading it and the unused entries being loaded in particular |
| 01:15 | <bradleymeck> | medium CLI is 100-200ms added boot time in Node |
| 01:16 | <devsnek> | that seems reasonable to me tbh |
| 01:16 | <bradleymeck> | cause you load all the possible values |
| 01:16 | <bradleymeck> | 100-200ms is totally insane for web |
| 01:16 | <bradleymeck> | and iot |
| 01:16 | <devsnek> | well they don't use a separate file |
| 01:16 | <bradleymeck> | ? |
| 01:16 | <bradleymeck> | they want it in-band yea... via module attributes. |
| 01:16 | <devsnek> | they're not bound to node's way of loading that data |
| 01:17 | <devsnek> | yeah module attributes would be fine if humans couldn't interact with them lol |
| 01:17 | <devsnek> | but they can |
| 01:17 | <bradleymeck> | devsnek: i've actively tried to think of ways we could load it faster |
| 01:17 | <devsnek> | they aren't just build output |
| 01:17 | <bradleymeck> | devsnek: there really isn't too much that can be done |
| 01:18 | <bradleymeck> | if you do the verification at runtime, you gotta pay the cost |
| 01:18 | <devsnek> | yes |
| 01:18 | <bradleymeck> | unused stuff is most of the cost |
| 01:18 | <devsnek> | the web has an entire thing for remapping imports |
| 01:18 | <bradleymeck> | yup |
| 01:19 | <devsnek> | for them it would be adding additional props to json |
| 01:19 | <devsnek> | which isn't slow |
| 01:19 | <devsnek> | at least compared to having the json in the first place |
| 01:19 | <bradleymeck> | if you list each json file that could be loaded? |
| 01:19 | <bradleymeck> | thats slow cause you have to list them all |
| 01:19 | <devsnek> | you do that already |
| 01:19 | <bradleymeck> | you don't in import maps |
| 01:19 | <devsnek> | the thing maps imports |
| 01:20 | <devsnek> | are you saying you think there will be more attributes than mapped imports? |
| 01:20 | <bradleymeck> | it does namespaced mapping, it doesn't have 1 entry per resource |
| 01:20 | <bradleymeck> | yes, since a mapping covers multiple resources |
| 01:20 | <bradleymeck> | can* |
| 01:20 | <devsnek> | ugh this is annoying |
| 01:21 | <bradleymeck> | https://wicg.github.io/import-maps/#import-map-scopes |
| 01:21 | <devsnek> | i think it makes perfect sense that you'd take a perf hit for this |
| 01:21 | <devsnek> | yeah I know how import maps work |
| 01:22 | <bradleymeck> | the perf hit can be done as needed with in-band |
| 01:22 | <bradleymeck> | rather than all at once, which saves a lot of time if you have unused stuff |
| 01:23 | <devsnek> | it shouldn't matter where the data is |
| 01:23 | <bradleymeck> | it does though |
| 01:23 | <bradleymeck> | even with my making things increasingly lazy and only parsing SRI on access to a resource in node, you still have to resolve the resource paths at startup |
| 01:23 | <devsnek> | i can see how it would if you have a dynamic import somewhere breaking the graph into pieces |
| 01:24 | <devsnek> | yeah i think that's kind of inherent to this problem though |
| 01:24 | <devsnek> | my point is that you need to map these attributes to every import location |
| 01:24 | <bradleymeck> | with in-band you don't have to resolve the paths since it is just w/e the import site is |
| 01:24 | <devsnek> | but you don't guarantee the data exists at every import site |
| 01:25 | <devsnek> | in terms of security that seems like a net loss to me |
| 01:25 | <bradleymeck> | sure, same with lots of things. use CSP or w/e to enforce that all sites must have the security attributes |
| 01:25 | <devsnek> | like yay its faster but we don't have the feature we set out to have |
| 01:25 | <bradleymeck> | you can just set a config that you must use the feature |
| 01:25 | <bradleymeck> | then while in dev it is optional |
| 01:25 | <devsnek> | you shouldn't need eslint to write correct code |
| 01:25 | <devsnek> | good code maybe |
| 01:25 | <bradleymeck> | linters/bundlers/formatters/etc. can add them |
| 01:25 | <devsnek> | but not correct code |
| 01:26 | <bradleymeck> | it would be correct without the attribute |
| 01:26 | <devsnek> | it wouldn't |
| 01:26 | <bradleymeck> | how so? |
| 01:26 | <bradleymeck> | you set a flag to enforce the attribute being used |
| 01:26 | <devsnek> | with missing `type`, the graph is invalid |
| 01:26 | <devsnek> | with missing `hash`, the graph is unsafe, and should be invalid because of that |
| 01:26 | <bradleymeck> | in a certain host that wants to ensure it is used, that seems reasonable |
| 01:27 | <devsnek> | we're not talking about hosts that don't want to use it though |
| 01:27 | <bradleymeck> | these are all things that you are treating as necessary rather than opt-in |
| 01:27 | <devsnek> | we should design the feature for people who will use it |
| 01:27 | <bradleymeck> | are you saying we should standardize an app config? |
| 01:28 | <devsnek> | maybe |
| 01:28 | <devsnek> | moreover i'm saying the current direction seems net negative |
| 01:28 | <devsnek> | i'd love to get more people thinking about alternatives but as soon as you say "not in band" they stop listening |
| 01:28 | <bradleymeck> | i dont saee anything you stated as removing value |
| 01:28 | <bradleymeck> | i'm in the not-in-band camp |
| 01:29 | <bradleymeck> | but i don't see anything concrete to find problems with |
| 01:29 | <devsnek> | i think its inherently bad that you can end up with out of sync config while actively trying to use it |
| 01:29 | <bradleymeck> | i see problems with not-in-band, the champions of attributes want different compromises than I do |
| 01:29 | <bradleymeck> | thats fine |
| 01:29 | <devsnek> | like to me that seems to invalidate the point |
| 01:30 | <bradleymeck> | you aren't configuring the type of the target with type= |
| 01:30 | <devsnek> | the point of this is to enforce a behaviour but you just kick the can down the road |
| 01:30 | <bradleymeck> | you are performing an assertion |
| 01:30 | <devsnek> | now you need assertions that you're performing assertions |
| 01:30 | <devsnek> | via eslint or whatever |
| 01:30 | <devsnek> | you literally just move the problem |
| 01:30 | <bradleymeck> | no, out of band is not a solution for these performance problems |
| 01:31 | <bradleymeck> | i am heavily in the oob solution camp |
| 01:31 | <bradleymeck> | but I see serious problems with it being the only way |
| 01:31 | <devsnek> | i don't understand how it fulfills the requirements |
| 01:32 | <bradleymeck> | i would still encourage all my teams to use oob, but it does not work as a solution for all situations |
| 01:32 | <bradleymeck> | which requirements? |
| 01:32 | <devsnek> | the reason this exists is to add verification where verification is missing |
| 01:32 | <devsnek> | right? |
| 01:32 | <bradleymeck> | in a way that is reasonable given platform constraints |
| 01:32 | <bradleymeck> | yes |
| 01:33 | <bradleymeck> | web has a perf constraint |
| 01:33 | <devsnek> | but then you have a problem |
| 01:33 | <devsnek> | you have an ability to add verification to the attributes |
| 01:33 | <devsnek> | but now you have to verify those exist |
| 01:33 | <devsnek> | you move the problem without solving it |
| 01:33 | <devsnek> | i guess you can say you make eslint solve it |
| 01:34 | <bradleymeck> | you solved the problem, but you have to do ahead of time verification still |
| 01:34 | <bradleymeck> | instead of verifying the type= of resources |
| 01:34 | <bradleymeck> | you now verify that all imports have type= |
| 01:34 | <bradleymeck> | different |
| 01:34 | <devsnek> | if somehow attributes were invisible to humans |
| 01:34 | <devsnek> | it would be fine |
| 01:35 | <bradleymeck> | idk how that would work |
| 01:35 | <devsnek> | exactly |
| 01:35 | <bradleymeck> | so, visible is fine |
| 01:35 | <devsnek> | so basically we're saying |
| 01:35 | <devsnek> | here's a feature |
| 01:35 | <devsnek> | don't ever actually use it |
| 01:35 | <devsnek> | leave it to babel output |
| 01:35 | <bradleymeck> | you should use it, when you want it |
| 01:35 | <devsnek> | no you as a human should not use it |
| 01:35 | <devsnek> | your tooling should emit it |
| 01:36 | <bradleymeck> | i don't agree with that statement |
| 01:36 | <bradleymeck> | you don't have to use it, but use it if you need it |
| 01:36 | <devsnek> | actually humans manually putting it in assisted by eslint seems usable |
| 01:36 | <bradleymeck> | import(x, {type:json}) is still useful |
| 01:36 | <devsnek> | i mean i wouldn't agree with that workflow |
| 01:37 | <devsnek> | dynamic imports seem fine |
| 01:37 | <devsnek> | but in a certain context |
| 01:37 | <devsnek> | you're importing x and you have no idea what it is but you know it should be json |
| 01:38 | <devsnek> | honestly that still has the multiple import location problem |
| 01:40 | <bradleymeck> | It asserts whatever loads won't mutate crap |
| 01:40 | <devsnek> | yeah it seems useful in very specific contexts |
| 01:41 | <devsnek> | where dynamic import is not being used to split the graph for lazy loading but to load something given to your application that you don't know |
| 01:41 | <devsnek> | like i said it technically still has the multiple import location problem but its unlikely you'd hit it |
| 01:41 | <bradleymeck> | If 2 callsites differ you might also be able to assert at least one will fail |
| 01:42 | <devsnek> | if js had standard resolve behaviour it could assert that attributes were consistent |
| 01:43 | <bradleymeck> | Hell even for static urls you are just asking the host to not let it mutate crap |
| 01:43 | <bradleymeck> | Sites get pwned |
| 01:43 | <bradleymeck> | It happens |
| 01:44 | <devsnek> | with static urls you can specify it once in a project config |
| 01:44 | <devsnek> | and sleep safe knowing you didn't forget one |
| 01:44 | <bradleymeck> | Perf cost |
| 01:45 | <devsnek> | how long does it take to verify a hash though |
| 01:46 | <bradleymeck> | Hash, no significant time . Loading all the paths... 10k entries is 300ms even super lazy |
| 01:47 | <bradleymeck> | And that's the total path count for a small CLI in node thanks to dynamic specifiers if you limit it to app root |
| 01:47 | <devsnek> | 10k entries lol |
| 01:47 | <bradleymeck> | Like 280 get used |
| 01:48 | <devsnek> | is that just npm being npm |
| 01:48 | <bradleymeck> | Yes and no |
| 01:48 | <devsnek> | well at least with imports you know exactly what is and isn't being loaded |
| 01:48 | <bradleymeck> | Total traversables statically is around 1-2k |
| 01:49 | <devsnek> | assuming you're not randomly `import()`ing absolute urls |
| 01:49 | <bradleymeck> | People do import non-static values |
| 01:49 | <devsnek> | right but usually they're just globbed |
| 01:50 | <bradleymeck> | Globbed? |
| 01:50 | <devsnek> | webpack will expand all possible importable things based on a static root in the import |
| 01:50 | <devsnek> | like `import('./assets/' + x)` |
| 01:50 | <devsnek> | will make webpack check everything in `./assets` |
| 01:51 | <bradleymeck> | Yup, both need tooling to aid this |
| 01:51 | <devsnek> | i should do a study of what % of sites have those webpack dynamic import maps |
| 01:51 | <devsnek> | i see them a lot |
| 01:57 | <rkirsling> | hmmmm |
| 01:58 | <rkirsling> | apparently `temporal dead zone` doesn't actually appear in the spec but the abbreviation `TDZ` is used without explanation in this algorithm alone: https://tc39.es/ecma262/#sec-runtime-semantics-forin-div-ofheadevaluation-tdznames-expr-iterationkind |
| 01:59 | <bradleymeck> | Yup |
| 01:59 | <bradleymeck> | We don't really have a non normative terms area |
| 01:59 | <rkirsling> | seems like it's been that way since ES2015 too, which is kind of shocking |
| 02:00 | <bradleymeck> | We have few notes and virtually no examples |
| 02:01 | <bradleymeck> | People have been reluctant to add non-normative text / had push back |
| 02:03 | <rkirsling> | I'm shocked that I can't find an issue either |
| 02:03 | <rkirsling> | I don't care how we resolve that but it's not a good look :-/ |
| 16:07 | <rwaldron> | Is anyone around that can wants to chat about import.meta real quick? devsnek MylesBorins or anyone with familiarity enough to discuss a specific step in the algorithm? https://tc39.es/proposal-import-meta/#sec-meta-properties-runtime-semantics-evaluation Step 4: If importMeta is undefined. |
| 16:08 | <rwaldron> | For the purpose of testing, is there a way to contrive that state? |
| 16:17 | <devsnek> | rwaldron: no |
| 16:17 | <devsnek> | at least not from js |
| 16:28 | <devsnek> | when host hooks are available via realms or whatever it should be possible though |
| 16:33 | <bradleymeck> | does the spec need to be updated? [[Meta]] vs [[ImportMeta]] |
| 16:35 | <devsnek> | bradleymeck: fixed in stage 4 pr |
| 19:19 | <devsnek> | bradleymeck: are realms not going to allow a custom global proxy? wouldn't that be needed for mocking browser environment. |
| 19:19 | <devsnek> | realms/compartments |
| 19:19 | <devsnek> | whatever the overall api is called |
| 19:20 | <bradleymeck> | they do but its complicated |
| 19:21 | <bradleymeck> | realms ~= new set of intrinsics / global |
| 19:21 | <bradleymeck> | compartments ~= host hooks / potentially global proxy / definitely global lexical scope |
| 19:21 | <bradleymeck> | so one is really just making a fresh env w/o host customization |
| 19:21 | <bradleymeck> | the other is all the host customization you might need |
| 19:22 | <bradleymeck> | and then some people want to define Agents eventually |
| 19:22 | <bradleymeck> | those are separate address spaces |
| 19:22 | <devsnek> | yeah I just meant like |
| 19:23 | <devsnek> | overall the realm+compartment api |
| 19:23 | <devsnek> | seems like global proxy would be needed for stuff like jsdom |
| 19:25 | <devsnek> | I wonder if we will ever have an agent api |
| 19:26 | <devsnek> | I guess that would conflict with web workers and worker_threads |
| 19:42 | <bradleymeck> | conflict? duplicate, sure |
| 19:44 | <devsnek> | it would be cool though |
| 20:06 | <theskillwithin> | is this correct? https://github.com/colorjs/javascript-yellow |
| 20:08 | <devsnek> | probably |
| 20:17 | <shu> | theskillwithin: the JS logo is a community thing, unaffiliated with TC39 |
| 20:18 | <shu> | theskillwithin: https://github.com/voodootikigod/logo.js/ is the repo |
| 20:18 | <shu> | perhaps you could contribute your package to that larger collection |
| 20:20 | <theskillwithin> | not my package just found it on google |
| 20:21 | <shu> | ah, i'm not sure what you mean by "correct" then |
| 20:23 | <theskillwithin> | i just want to use the javascript color associated with javascript to theme https://d4dnjdsd285hx.cloudfront.net/ |
| 20:25 | <devsnek> | "javascript" itself isn't even official |
| 20:25 | <devsnek> | we make ECMAScript here |
| 20:28 | <bradleymeck> | "javascript" is trademarked to oracle |
| 20:29 | <bradleymeck> | always call it JS if you can avoid the long name |
| 20:38 | <theskillwithin> | wow did not know that |
| 20:38 | <theskillwithin> | i thought u lost ur tademark very easily if it was common lingo |
| 20:40 | <bradleymeck> | IANAL but i believe as long as it is defended it won't be lost |
| 20:41 | <bradleymeck> | 2018 it was |
| 20:41 | <bradleymeck> | also law varies per area of the world |
| 20:56 | <devsnek> | oracle is known for issuing takedowns on the mac app store for things with "javascript" in the name |
| 20:57 | <devsnek> | well, known to issue |