throwitaway1123

Joined 2 years ago

Karma

469

Submissions

319

Member since

Nov 28

Created this account 11/23. Might throw it away at some point.

View on Hacker News

Recent submissions

Comment · 1 year ago

There's actually a library called ast-grep which does something very similar to what you're describing. They have an example in their introduction which performs a find and replace operation on a JS AST using a pattern:

  ast-grep --pattern 'var code = $PAT' --rewrite 'let code = $PAT' --lang js

https://ast-grep.github.io/guide/introduction.html

Comment · 1 year ago

For anyone looking for context on smooshgate: https://developer.chrome.com/blog/smooshgate

Comment · 1 year ago

Yes, as you pointed out, not only can bundlers tree shake namespace imports, but they're literally used in the esbuild documentation to demonstrate the concept of tree shaking.

The issue you linked to is referring to the case in which you import a namespace object and then re-export it. Bundlers like webpack and rollup (which vite uses in production) can tree shake this pattern as well, but esbuild struggles with it.

If you're using esbuild instead of this:

  import * as someLibrary from "some-library"
  someLibrary.someFunction()
  export { someLibrary }

You can still do this:

  import * as someLibrary from "some-library"
  someLibrary.someFunction()
  export * from "some-library"
  export { default as someLibraryDefault } from "some-library"

Tree shaking works as expected for downstream packages using esbuild in the second case, which someone else in the linked issue pointed out: https://github.com/evanw/esbuild/issues/1420#issuecomment-96...

Comment · 1 year ago

Alternatively, with namespace imports in JS you can write [1]:

  import * as someLibrary from "some-library"
  someLibrary.someFunction()

Which works pretty well with IDE autocomplete in my experience.

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Comment · 1 year ago

This of course requires your build tool to actually understand the TS type system, which is why it's not supported in tools like esbuild and tsx (which uses esbuild under the hood).

Comment · 1 year ago

> I do wonder if this makes the importable gets (via type: json) a reality like assert was going to.

Yes, the JSON modules proposal is finished.

https://github.com/tc39/proposal-json-modules

https://caniuse.com/mdn-javascript_statements_import_import_...

Comment · 1 year ago

Which browsers have you tested this in? I ran the feature detection script from the Chrome docs and neither Safari nor Firefox seem to support fetch upload streaming: https://developer.chrome.com/docs/capabilities/web-apis/fetc...

  const supportsRequestStreams = (() => {
    let duplexAccessed = false;
  
    const hasContentType = new Request('http://localhost', {
      body: new ReadableStream(),
      method: 'POST',
      get duplex() {
        duplexAccessed = true;
        return 'half';
      },
    }).headers.has('Content-Type');
  
    return duplexAccessed && !hasContentType;
  })();

Safari doesn't appear to support the duplex option (the duplex getter is never triggered), and Firefox can't even handle a stream being used as the body of a Request object, and ends up converting the body to a string, and then setting the content type header to 'text/plain'.

Comment · 1 year ago

Enums and parameter properties can be enabled with the --experimental-transform-types CLI option.

Not being able to import TypeScript files without including the ts extension is definitely annoying. The rewriteRelativeImportExtensions tsconfig option added in TS 5.7 made it much more bearable though. When you enable that option not only does the TS compiler stop complaining when you specify the '.ts' extension in import statements (just like the allowImportingTsExtensions option has always allowed), but it also rewrites the paths if you compile the files, so that the build artifacts have the correct js extension: https://www.typescriptlang.org/docs/handbook/release-notes/t...

Comment · 1 year ago

In Node 22.7 and above you can enable features like enums and parameter properties with the --experimental-transform-types CLI option (not to be confused with the old --experimental-strip-types option).

Comment · 1 year ago

Node does have a permissions system, but it's opt in. Many runtimes/interpreters either have no sandbox at all, or they're opt in, which is why Deno's sandbox is an upgrade, even if it's not as hardened as iptables or Linux namespaces.

Comment · 1 year ago

> you can't just allow exact what you need in that category? You have to allow the entire category and then deny everything you don't want/need?

No, you can allow access to specific domains, IP addresses, filesystem paths, environment variables, etc, while denying everything else by default. You can for instance allow access to only a specific IP (e.g. `deno run --allow-net='127.0.0.1' main.ts`), while implicitly blocking every other IP.

What the commenter is complaining about is the fact that Deno doesn't check which IP address a domain name actually resolves to using DNS resolution. So if you explicitly deny '1.1.1.1', and the script you're running fetches from a domain with an A record pointing to '1.1.1.1', Deno will allow it.

In practice, I usually use allow lists rather than deny lists, because I very rarely have an exhaustive list on hand of every IP address or domain I'm expecting a rogue script to attempt to access.

Comment · 1 year ago

The repeat directive I mentioned as an example of a custom looping control flow construct used in a tagged template is the exact same one another commenter later mentioned (and you responded to) here by the way: https://news.ycombinator.com/item?id=44441002

Comment · 1 year ago

I certainly don't think I'm talking past you, but I can't force you to elaborate.

Comment · 1 year ago

JSX was also created with the intention of using traditional conditional/looping constructs, but that hasn't stopped Solid and Preact from repurposing it for fine grained reactivity. Preact's signal implementation has Solid-like Show/For components [1].

I won't speak for the author of the proposal, but given that Lit itself has special control flow mechanisms for conditionals and loops (the cache and repeat directives respectively [2][3]), I can't imagine the proposal being too opposed to these mechanisms.

[1] https://github.com/preactjs/signals/blob/eae850a9f3aa62e505a...

[2] https://lit.dev/docs/templates/conditionals/#caching-templat...

[3] https://lit.dev/docs/templates/lists/#the-repeat-directive