|
IAmKale posted:So here's my question: How can I break up and organize my code into multiple files, but get tsc to output a single JavaScript file in basic ES5? Use Webpack.
|
# ? Jul 10, 2017 19:08 |
|
|
# ? Jun 1, 2024 06:04 |
|
Roadie posted:Use Webpack. and Babel
|
# ? Jul 10, 2017 19:12 |
|
Grump posted:and Babel You don't need Babel if it's an all-Typescript project. Just set the tsconfig.json to target ES5.
|
# ? Jul 10, 2017 19:30 |
|
ROFLburger posted:That's been my experience too, and it certainly seems like it's more common with JS libraries than anything else I've worked with If they take the time to write documentation they'll just get upstaged by the flavor of next month!
|
# ? Jul 10, 2017 19:33 |
|
Skandranon posted:You can use TypeScript internal namespaces to manage the code across multiple files, and then do a simple concatenation of all the files. I usually use gulp-typescript and gulp-concat to do this, but you might be able to get tsc to do it by itself. PM me for a specific example if you need one. Roadie posted:Use Webpack.
|
# ? Jul 10, 2017 19:53 |
|
Munkeymon posted:I'm not sure what you mean by that, but I think you just need to add btnDownload.x and btnDownload.y to the form data like so That still doesn't work. If I try to append the data outside the formRequest definition it gives me an error, if I do it within the definition it gives me the HTML again This gives me an error code:
code:
code:
icantfindaname fucked around with this message at 21:02 on Jul 10, 2017 |
# ? Jul 10, 2017 21:00 |
|
IAmKale posted:So here's my question: How can I break up and organize my code into multiple files, but get tsc to output a single JavaScript file in basic ES5? This has become a more complicated question after TypeScript developers found out that people were using TypeScript wrong, so they fixed it and you can't really do this with TypeScript alone anymore. They would say that concatenating the files is wrong too. The simplest and best solution: Emit "es2015" targeted at "es5" compatibility. This will give you a folder full of your ts files, as es5 files, with es2015 import statements. Then use Rollup because Webpack is the worst thing to have ever happened. Rollup is really small, it will watch, and it will properly output a single file for you.
|
# ? Jul 10, 2017 21:01 |
|
icantfindaname posted:That still doesn't work. If I try to append the data outside the formRequest definition it gives me an error, if I do it within the definition it gives me the HTML again I bet the FormRequest isn't serializing back out to the Phantom context OK, I think we can skip the whole eval thing and use http://docs.casperjs.org/en/latest/modules/casper.html#getformvalues like this JavaScript code:
|
# ? Jul 10, 2017 21:33 |
|
IAmKale posted:Ah, internal namespaces and concatenation. I'll take a look at that and PM you if I end up banging my head against a wall. Spend an hour or two dedicated to learning webpack. Its easy after that. Here's a copy/paste of the webpack config from the webpack-bundled react typescript project I'm working on right now. code:
|
# ? Jul 10, 2017 21:41 |
|
huhu posted:
In addition to the already posted you could replace the "for" loop with "list.forEach" to get the same effect as the given solution: code:
|
# ? Jul 10, 2017 21:50 |
|
Munkeymon posted:I bet the FormRequest isn't serializing back out to the Phantom context Okay, it worked. Thanks!
|
# ? Jul 10, 2017 23:20 |
|
IAmKale posted:So here's my question: How can I break up and organize my code into multiple files, but get tsc to output a single JavaScript file in basic ES5?
|
# ? Jul 11, 2017 01:24 |
|
Honest Thief posted:Maybe this is just me bitching and being annoying but it seems every other article about some new js tool barely covers the basic use cases. Case in point, I'm trying to figure out the syntax it accepts for custom routing, only the given example on the repo doesn't work, and none of the article I can find seem to consider the possibility of wanting to have custom routes. Yeah, that's javascript. Even seemingly well documented frameworks either document a function superficially*, or there have been breaking changes in the api in minor versions and nobody bothered to update the documentation/tutorials. *)something like "the function takes a configuration object and a callback" without telling the structure of the object or the parameters the callback will be called with
|
# ? Jul 11, 2017 08:18 |
|
Maybe this is all nostalgia or something but I seem to recall this not being the case 4, 5 years ago, or at least not the norm. Although I bet it's related to how everyone started making frameworks or whatever in order to pump up their notoriety.
|
# ? Jul 11, 2017 09:48 |
|
Wheany posted:there have been breaking changes in the api in minor versions and nobody bothered to update the documentation/tutorials. the node community has a hard-on for semantic versioning but NEVER gets it right. I cannot count how many times the default npm install mode of pinning to the major version not actual mattering at all and entire projects breaking from a minor release. Honest Thief posted:Maybe this is all nostalgia or something but I seem to recall this not being the case 4, 5 years ago, or at least not the norm. Although I bet it's related to how everyone started making frameworks or whatever in order to pump up their notoriety. I blame npm and the node community in general for a shitload of the issues. How many package managers do you know with a huge staff, multi-hundred million dollar valuation and funding? NPM is the only one I'm aware of!
|
# ? Jul 11, 2017 15:35 |
|
Thank you all for pointing me back towards Webpack and the React/TypeScript tutorial. I was able to produce the desired output by emitting es2015 modules targeting ES5, then bundling those using awesome-typescript-loader via Webpack. It even made it painless to incorporate polyfills for window.fetch() and Promises without having to add anything to my TypeScript files, just a couple of strings to the Webpack config's entry array
|
# ? Jul 11, 2017 17:24 |
|
IAmKale posted:Thank you all for pointing me back towards Webpack and the React/TypeScript tutorial. I was able to produce the desired output by emitting es2015 modules targeting ES5, then bundling those using awesome-typescript-loader via Webpack. It even made it painless to incorporate polyfills for window.fetch() and Promises without having to add anything to my TypeScript files, just a couple of strings to the Webpack config's entry array Webpack is pretty awesome if you can get past the initial hump. Even if typescript supported bundling, I'd still use webpack. It brings too many other useful features to the table.
|
# ? Jul 11, 2017 17:28 |
|
webpack is cool as long as they stop completely rewriting it every major version.
|
# ? Jul 11, 2017 17:54 |
|
necrotic posted:webpack is cool as long as they stop completely rewriting it every major version. Well, they didnt do that for 2 -> 3...
|
# ? Jul 11, 2017 18:32 |
|
But with HTTP2 you don't need to concatenate so Webpack is useless now.
|
# ? Jul 12, 2017 04:26 |
|
The Merkinman posted:But with HTTP2 you don't need to concatenate so Webpack is useless now. Looking forward to using HTTP2 in 2027
|
# ? Jul 12, 2017 11:41 |
|
Wheany posted:Looking forward to using HTTP2 in 2027 Support is already pretty good http://caniuse.com/#search=http2
|
# ? Jul 12, 2017 14:14 |
|
The Merkinman posted:But with HTTP2 you don't need to concatenate so Webpack is useless now. It's my understanding you don't want to be sending a lot of small files, even with HTTP/2. Some level of bundling is still a good idea, just not the current approach of "everything in one file". At least in React land there's been a lot of work towards splitting large projects up into multiple bundles that lazily load when required. That seems like the right approach going forward, which still requires webpack or similar.
|
# ? Jul 12, 2017 14:56 |
|
The Merkinman posted:But with HTTP2 you don't need to concatenate so Webpack is useless now. http://w4t.pw/5kcz
|
# ? Jul 12, 2017 15:11 |
|
necrotic posted:the node community has a hard-on for semantic versioning but NEVER gets it right. I cannot count how many times the default npm install mode of pinning to the major version not actual mattering at all and entire projects breaking from a minor release. Yep, pin your dependencies kids, ^ cannot be trusted to give you a good time across machines/servers.
|
# ? Jul 12, 2017 15:38 |
|
It's just great that NPM defaults to the carrot. At least they have a package lock finally?
|
# ? Jul 12, 2017 15:50 |
|
necrotic posted:It's just great that NPM defaults to the carrot. At least they have a package lock finally? I just always used 'npm shrinkwrap' before we switched to yarn.
|
# ? Jul 12, 2017 15:53 |
|
Kekekela posted:I just always used 'npm shrinkwrap' before we switched to yarn. Yeah everyone should have been. The fact that it took them 5 major versions to make shrinkwrap-like behavior the default is indefensible, though.
|
# ? Jul 12, 2017 18:10 |
|
I'm trying to add a style to YOSPOS, and for the life of me I can't remove the background image and color for the seen threads, though when I go into in inspector and disable them, it works.code:
|
# ? Jul 12, 2017 21:21 |
|
necrotic posted:Yeah everyone should have been. The fact that it took them 5 major versions to make shrinkwrap-like behavior the default is indefensible, though. Except now the lockfile doesn't actually get updated when you change package.json, only when you run npm. This means you can't update things via package.json, as it will keep using your old lock file. So you just have to habitually delete the lock file (or disable it entirely), or update all packages 1 at a time via the command line.
|
# ? Jul 12, 2017 21:54 |
|
LP0 ON FIRE posted:I'm trying to add a style to YOSPOS, and for the life of me I can't remove the background image and color for the seen threads, though when I go into in inspector and disable them, it works. Might be a race condition that you're executing when the window is ready but not the body of the DOM? Also, for fun you could throw an !important beside the `none` for background-image to enforce it above everything else.
|
# ? Jul 12, 2017 22:33 |
|
Surprise: NPM is still bad!
|
# ? Jul 12, 2017 22:35 |
|
Video Nasty posted:Might be a race condition that you're executing when the window is ready but not the body of the DOM? Also, for fun you could throw an !important beside the `none` for background-image to enforce it above everything else. onload fires after _everything_ has loaded, so the DOM is definitely available.
|
# ? Jul 12, 2017 22:35 |
|
Video Nasty posted:Might be a race condition that you're executing when the window is ready but not the body of the DOM? Also, for fun you could throw an !important beside the `none` for background-image to enforce it above everything else. You sure something else isn't also assigning something to window.onload?
|
# ? Jul 12, 2017 22:48 |
|
I actually took a look at that and there wasn't anything on it. Not a bad idea to try the addEventListener method a shot, the code definitely works.
|
# ? Jul 13, 2017 00:44 |
|
package-lock.json "describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates." How come pulling down a repo and running npm i modifies package-lock.json? I develop on two different computers and it's driving me crazy. I'll add a package on my laptop, commit package.json and package-lock.json, and then when I pull the change and npm i, I get a different package-lock.json. Doesn't this defeat the purpose? Am I misunderstanding why package-lock.json exists?
|
# ? Jul 13, 2017 01:25 |
|
LP0 ON FIRE posted:I'm trying to add a style to YOSPOS, and for the life of me I can't remove the background image and color for the seen threads, though when I go into in inspector and disable them, it works. code:
edit: sans jquery code:
geeves fucked around with this message at 03:07 on Jul 13, 2017 |
# ? Jul 13, 2017 02:56 |
|
porksmash posted:How come pulling down a repo and running npm i modifies package-lock.json? I develop on two different computers and it's driving me crazy. I'll add a package on my laptop, commit package.json and package-lock.json, and then when I pull the change and npm i, I get a different package-lock.json. Doesn't this defeat the purpose? Am I misunderstanding why package-lock.json exists? It sounds like you've got two different versions of npm 5.0.x. They're still fiddling with the fine details of the package-lock.json format.
|
# ? Jul 13, 2017 09:23 |
|
Video Nasty posted:Might be a race condition that you're executing when the window is ready but not the body of the DOM? Also, for fun you could throw an !important beside the `none` for background-image to enforce it above everything else. Possibly, but I don't know what it is. !important didn't do anything. geeves posted:
That screen shot is precisely what is happening with my original code too. I can't remove the background image and color for the seen threads, leaving that ugly green backgrounds there. Not too say that my style is not ugly.
|
# ? Jul 13, 2017 14:39 |
|
|
# ? Jun 1, 2024 06:04 |
|
LP0 ON FIRE posted:That screen shot is precisely what is happening with my original code too. I can't remove the background image and color for the seen threads, leaving that ugly green backgrounds there. Not too say that my style is not ugly. I made a change last night and forgot to edit it in. Remove the 'seen" classes. It's the only way I could remove the background in the inspector. code:
|
# ? Jul 13, 2017 15:23 |