dim path
Hey there,
what do I need to do to proplerly import a module into html using a script tag after I've bundled all the scripts together using rollup? I'm loading the bundle via the html script tag as as module, but all my namespaces appear to be gone, and I have no idea how to fix this.
Any idea what I might be doing wrong? I'm transpiling several typescript files to JS, and bundling those together using the rollup typescript plugin.
kind basalt
Hey there,
what do I need to do to proplerly import a module into html using a s...
all my namespaces appear to be gone
and this isn't what you want? if not, why are you using a bundler?
the main purpose of bundling is to produce a single script that contains your application logic plus all of its dependencies
dim path
> all my namespaces appear to be gone
and this isn't what you want? if not, why ...
I'm using a bundler because my browser won't load my js source files since I'm importing them without a file extension in TS
that means that my browser won't load it
stackoverflow said that I should use a bundler but this has only caused me issues so far
kind basalt
yeah, that's like saying "i have a nail sticking up on my deck" and someone suggesting "buy a steamroller" to fix it
dim path
so what should I be doing then?
kind basalt
the simplest thing would be to add extensions to your import specifiers
but i know some people find that very upsetting for reasons i don't understand
dim path
the simplest thing would be to add extensions to your import specifiers
will tsc change those on compilation? also I thought ts didn't like imports with file extensions
kind basalt
no. tsc never touches your import specifiers. like almost everything outside of types in TS, the resulting JS is the same as what you write in your source code
dim path
I mean, will ts change a .ts to a .js extension?
kind basalt
no. you write import { blah } from './foo.js' and what's what you get in your output
in your codebase you might have a file named foo.ts that would get compiled to foo.js
dim path
ugh I hope that won't mess with my language server
dim path
typescript-language-server
kind basalt
looks like that's just a wrapper for tsserver, so yeah should be fine
this is the standard way to write typescript targeting ESM, so any non-broken dev setup should be happy with it
dim path
alright, thanks, that worked!
I'm now stuck with Cannot use import statement outside a module though
I was hoping rollup would deal with that as well
kind basalt
what's the context?
dim path
well it's <script src="./lib.js">
kind basalt
you may need a type="module" attribute on the relevant <script> tag?
yeah, you have to tell browsers to interpret <script>s as ESM
dim path
you may need a `type="module"` attribute on the relevant `<script>` tag?
I've tried that before but it didn't seem like my library would be accessible from within the html then
kind basalt
it's been a while since i've done this kind of frontend stuff, but if you mean like referring to stuff from onclick attributes or whatever then yeah. stuff in modules aren't part of the global scope
dim path
yeah that's quite annoying
rollup had a way of dealing with that, but since that's not working I have no idea
kind basalt
well aside from the import specifiers, there may be other reasons to bundle your code (and emit something that's not a module). that can often lead to better performance because bundlers can see "the whole picture" and strip out dead code, and also the client ends up having to make fewer requests
but if you do that then i would go all-in on the bundler approach and try to use a single script from your frontend
if you don't want to do that and instead want to deliver modules, i'd have to do some research but i'm sure there's a way to get exports into the global scope
dim path
but if you do that then i would go all-in on the bundler approach and try to use...
oof I was triyng to avoid just that for readability's sake
kind basalt
sourcemaps can help there
kind basalt
if you don't want to do that and instead want to deliver modules, i'd have to do...
i think maybe you can attach things to globalThis from inside modules? so you could have a "main" module that imports the specific stuff you need and then assigns it to properties on globalThis, which you should be able to access from the HTML document's global scope
if that works the way i think it will, sounds kinda nice to have an explicit listing of globals, rather than being able to access absolutely everything like you could in pre-module JS (which could lead to lots of accidental coupling)
like i said though i haven't done frontend stuff in a while, so i don't entirely know what i'm talking about
dim path
i think maybe you can attach things to `globalThis` from inside modules? so you ...
yeah I've read this as well but then I'd have to do double the work inside the entire project. I'm confused why such a simple task requires so much effort
is webdev just annoying like this?
dim path
like i said though i haven't done frontend stuff in a while, so i don't entirely...
well alright
I'll see if I can figure this out somehow
thank you very much for your help!
kind basalt
uh webdev is annoying for a lot of reasons yeah, but what you're hoping to do is kind of a contradiction: modules are (as the name implies) meant to modularize your code. the whole point is to not pollute the global scope. if you specifically don't want that, then don't use modules
dim path
uh webdev is annoying for a lot of reasons yeah, but what you're hoping to do is...
huh. I was seeing modules more as a way of splitting up a project into multiples files
I honestly have no idea how to even do that without modules
kind basalt
you can have as many <script> elements as you want, all referring to different .js files. without type="module" you can think of them as kinda getting all concatenated together into one big imaginary global script
and attributes like onclick whose values are JS strings are also evaluated in that same global scope
dim path
but how would I then be able to talk between script files?
without moving all my code into the html script tags
kind basalt
you can access variables willy-nilly across scripts
not sure if that's exactly what you're asking though
dim path
I mean, it kinda is, but I don't think the language server will play nicely with that
kind basalt
TS configured properly can recognize files as scripts rather than modules
but i'm mostly speaking in terms of the execution environment here, not how you emit those scripts from your source code
another angle which may not be fashionable these days: back when i did do more frontend stuff eons ago there was a push towards "unobtrusive JS". you wouldn't tie your DOM to specific JS via onclick attributes and the like. instead you'd go the other way and query the DOM from your JS and attach event handlers there. so the HTML document itself doesn't have to know anything at all about your JS
you'd use class/id attributes and the DOM hierarchy to find the relevant elements from the JS side, and if you need to attach state to the DOM you can write to data-* attributes and similar from JS
i get the impression that these days most frontend folks use a giant stack of abstractions like virtual DOMs via libraries like react/vue/etc though, and most people don't even care about what's actually going on under the hood
dim path
another angle which may not be fashionable these days: back when i did do more f...
yeah I thought about that as well but that's going to get quite tedious quickly. Same reason why I want to avoid writing window.foobar for every single one of my functions
dim path
i get the impression that these days most frontend folks use a giant stack of ab...
I'm staring to see the appeal haha
kind basalt
what kind of site are you building? would you say it's more of a "web application" or more like a traditional "document"?
dim path
TS configured properly can recognize files as scripts rather than modules
this is a good idea actually
Just looking at the tsconfig it seems like I can set include paths. Doesn't appear to be working right now but I'm hopeful
dim path
what kind of site are you building? would you say it's more of a "web applicatio...
more of a web application I'd say
kind basalt
this is a good idea actually
Just looking at the tsconfig it seems like I can se...
IIRC as long as the module setting or nothing else is convincing tsserver to treat every file as a module, then module-ness is inferred from the presence of import/export statements (any file without any imports or exports should be recognized as a script)
kind basalt
more of a web application I'd say
but yeah if this is the case and you have a lot of frontend state/rich interactivity/etc, then it might be worth considering something like react/vue/angular/etc
dim path
would definitely be a sane choice but I don't think I'm ready to dive into yet another new environment again
I was trying to avoid webdev anyway haha
kind basalt
what's your comfort zone? many other stacks have compile-to-JS (with varying degrees of support for also creating the UIs themselves in a non-webby-way)
like i've toyed with Scala.js in the past, for example
(feels weird to recommend this kind of approach on a typescript discord server, heh)
dim path
what's your comfort zone? many other stacks have compile-to-JS (with varying deg...
Vanilla TS mostly, little bits of JS if I need to
kind basalt
oh, just backend/non-browser-runtimes then?
dim path
this is a good idea actually
Just looking at the tsconfig it seems like I can se...
yup, this actually works perfectly now!
All I needed to do was add the include option to my config and include every TS file, and then export all necessary functions from my namespaces
now I don't need module type script imports anymore and bare script tags work now, as you suggested
dim path
oh, just backend/non-browser-runtimes then?
exactly