Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I think it's more that depending on your point in time, build process and environment, `import` has changed meaning every couple of years.

I consider myself having deeper knowledge about JS and node than any other language, having spent more total time in it than anything else (except maybe bash).

I have a clearer understanding of what import/require really does in most other languages.

The flow-chart complexity and possible outcomes of what `import` really does in JS/TS are certainly greater than anything else I've encountered.

(I do find go's repository-based approach quite frustrating to work with when forking dependencies but at least it's straight-forward)



> (I do find go's repository-based approach quite frustrating to work with when forking dependencies but at least it's straight-forward)

If I understand your point correctly, then that's a non-issue since modules are here.

In the go.mod file you have the current module name, and all imports of yourself will use the current repository, instead of calling the original.

So you fork the repository, but keep the original name in the go.mod file, then you don't have to modify any imports.


Straight-forward these days indeed.

https://golang.org/doc/modules/managing-dependencies#unpubli...

I still find the whole gopath/gomodules thing unfortunate but it is what it is at this point (and frankly that’s a bit out scope since we’re talking imports here.. if we’re talking about the state of packaging then JS absolutely has competition; e.g. https://xkcd.com/1987/)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: