Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

node / typescript workflows

Đang mở
  • Có gì không ổn?
#4 6 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Đình trệ
Công nghệ
javascript, node.js, typescript
Lĩnh vực
backend, build-system, developer-experience

Hướng nghiên cứu

Bắt đầu bằng cách đọc handler hashql và tài liệu hiện có trong /examples, sau đó lập sơ đồ xem việc sao chép mã nguồn, các import tương đối đã được biến đổi và việc transpile TypeScript sẽ kết hợp với nhau như thế nào. Các câu hỏi còn bỏ ngỏ về việc xác định các import đã băm và hỗ trợ import tĩnh so với import động cần được quyết định trước khi có thể xác định tiêu chí hoàn thành.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

enhancement
Better node / typescript workflows

Today, it is possible to call arbitrary node code server side within a template literal.

I think this is cool but in practice it's not that ergonomic to work with, it's very stringly typed and you might need to escape your code (e.g. is there a template literal inside your template literal).

It also completely removes the ability to have typed languages because all that type information that would normally be analyzed by a compiler is "trapped" inside a string.

I suggest we build in support for hashed modules.

Hashed modules

Hashed modules simply copy a module's subtree in the same way we copy source code. But hashql generates a transformed replica of those modules (updating relative imports for example).

From an editors perspective it's just a dynamic import with an async default export. Both JS and TS will be able to find the original source file and identify the type information from that source file.

So if you have some js module, you can just dynamically import it and call it:

import('./my-lambda.js').then(
  ({ default:f }) => f({ a: 1, b: 2 })
)

Which is compiled to something like:

hashql.module(<hash-of-compiled-subtree>).then(
  ({ default:f }) => f({ a: 1, b: 2 })
)

The cool thing to note is, this is 100% typed. An IDE will chug along not knowing we've done anything at all to the source, and it will simply look at the originally referenced path and gather type information itself.

Typescript

The above will work with typescript, but hashql doesn't yet have an example of transpilation of source in the hashql handler. I think this is pretty easy to do as a build step, but it'd be good to have in /examples so people can figure it out. It'd also be good to have some ootb modules for rigging up common workflows (e.g. hashql-rollup-typescript or hashql/rollup/typescript).

Static Usage

This can definitely work for static imports too, with a few restrictions, all exported values are async.

So if you have a module:

export const a = 1

And you import it, a will be a Promise

import * as example from './example'

example.a.then(console.log) // logs 1

In practice that won't be too much of an issue, if you want code to run on the server it's likely async anyway. But I think it'd be valuable for the compile step to warn that a hashed module was imported with non async imports - to avoid confusion.

This problem is mitigated with dynamic imports because async is enforced, But I think we shouldn't exclude static imports, it just feels nice to do something like import * as api from './api' and then call api.createUser(user) from the client as if it was all in the same process.

Questions

How do we identify which imports should be hashed, and which shouldn't is an open question. We could have a comment, or we could have a config file with path globs. Because this doesn't use template literals it requires some new interface design work in that department.

Why?

This feature will give hashql editor support for free. There's no reason we can't take this same technique and use it with other language's module systems (e.g. python/rust/go), and those editors will all already know how to get the type information from those imports.

This relieves a lot of pressure from the library to do special custom things like generating tsd's or the like.

Ngôn ngữ chính
JavaScript
Star
78
Fork
5
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của porsager/HashQL

Tất cả issue của porsager/HashQL

Issue tương tự

Thêm issue về JavaScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.