denoland / dotland

[Archived] deno.land website
https://deno.land
MIT License
957 stars 626 forks source link

Support dynamic server-generated modules #2438

Closed mimbrown closed 2 years ago

mimbrown commented 2 years ago

Motivation

JavaScript pain point: tree shaking is hard in a dynamic language. So people generally have the choice to use convenient third party libraries and accept the bloat, or roll their own functionality and accept the associated time and cost.

Proposal

Allow, as a part of the Deno module hosting service, some server-side generation of imported code.

Example 1

Person A developed a nifty phone number input that supports formatting internationalized phone numbers. It, of course, supports all however many 100 odd dialing codes and formats out there. Person B wants to use Person A's cool library, but only needs to support the US and Mexico. He doesn't need the whole giant list of every country's metadata. Wouldn't it be great if Person B could just:

import IntlInput from "https://deno.land/x/cool_intl_input@0.0.1/mod.ts?countries=usa,mex";

This is an open-ended proposal that would require denoland to run some third-party written server code at some point to generate the export, which I accept may be a non-starter.

Example 2

I'm thinking of Rust features syntax. Wouldn't it be great for library developers to have an official path for including optional features in their libraries? One easy path would be just conditionally stripping out the things between quotes following some standard syntax, something like this (I'm not proposing this syntax, just an example):

// <feature name="verbose-logging">
console.warn('Some detailed warning');
// </feature>

// Or, rust inspired...
// #[cfg(feature = "my-feature")]
export function myFunction() {
    // ...
}

Or possibly more robust is to go the more vite-like route and have some variable attached to import.meta, replaced at serve-time with true or false (so fully tree-shakeable):

if (import.meta.feature('verbose-logging')) {
  console.warn('Some detailed warning');
} else {
  console.warn('Whoops');
}

Both of these would support imports like the following:

import * as mod from "https://deno.land/x/my_lib@0.0.1/mod.ts?feature=verbose-logging";

And these would be baked in, meaning there's no third party code running at any point to support this.

Conclusion

I know that this could be done right now by anyone who wants to set up their own server. I also know this could be very badly abused. I'm proposing it here because Deno is in a position to set standards, limits, and best practices for this kind of thing, and make it an officially supported path for library developers in a robust and safe way. The possibilities are pretty exciting to me. So I just want to start the conversation.

kitsonk commented 2 years ago

While this is an interesting concept or feature, it really is out of scope for dotland anytime in the near future.

There are a lot of moving parts and semantics that would need to be defined as well as widespread adoption by some/all of the community, as well as need to ensure it integrates well with the wider eco-system. Anything that requires syntax level annotations is going to be problematic and likely devolve into an argument or make code that is broadly incompatible with other runtimes.

So respectfully declined.