Develop Reference

Reduce size of sveltekit app deployed with node-adapter

I have written a sveltekit app that I would like to deploy for instance on AlwaysData.
On the AlwaysData servers I can use up to 100Mo. I thought this would be plenty for the very small app I have written. But it is not the case : my app is more than 400Mo.
I looked into it and noticed two things :
after building the app, there still remains a node_modules folder that is not bundled into the app.
this node_modules folder is more than 400Mo although I only use a few simple libraries.
Hence my question:
is there a way to bundle the node_module packages into my app? This would keep only the necessary stuff which is only a few kilobytes.
or is there a way to tell javascript to import the minified version of the package in the dist folder when in production.
Following are the libraries I use and the size they should be according to bundlephobia :
#primsa/client : 233B
#supercharge/request-ip : 3.8kB
axios : 17.6kB
ramda : 53.4kB
sprintf-js : 3.5kB
So how does an app that should take less than a 100kB end up taking 400MB ? Even from an environmental point of view, this looks a bit annoying...

You only need to deploy the build folder nothing more.

Combining Static Sites + Client Side Rendering (React, Gatsby)

I want to build a web app with React.
When users visit the site, they will see a Landing Page, can go to a Pricing Page, an About page, a Blog. etc. They can also Sign Up or Log in and then there's the actual app. I would like render certain pages (Landing,Pricing,About,Blog) statically, but would like to leave everything behind the SignUp/Login-Wall client-side rendered.
(First, because it cannot be static, since this is dynamic content. And also, because I do not care about SEO here anyways, so a major reason for next.js falls away, since the app is behind a SignUp/Login Wall anyways.)
Questions: First of all: Does this make sense? And secondly: How could I implement something like this? I haven't found anything online! Is this unheard of? I would like to use Gatsby.js for my static content, but I am not sure how to bring the client-side-rendered bit into the mix. I have worked with create-react-app before, which does client-side-rendering, - but I am not sure how I would go about the implementation?

I will try to explain the process behind jamstack-hackathon-starter (which #ksav commented).
It is a starter template for gatsby that allows you to save static pages in-
conjunction with dynamic pages (client-side react app) - a "Hybrid Gatbsy App".
Manual Steps:
1. Create a folder src/app which will contain your client-side react app.
2. Create a file in src/pages called app.js, with the following contents:
// I'm using create-react-app's structure
import App from '../app/src/App' // make sure this path corresponds to your path
export default App
Now install gatsby-plugin-create-client-paths:
npm install --save gatsby-plugin-create-client-paths
Configure it by adding it to gatsby-config.js like so:
plugins: [
{
resolve: `gatsby-plugin-create-client-paths`,
options: { prefixes: [`/app/*`] },
},
...
This will result in everything within /app to only be rendered in the browser (ie client-side).
Go to your browser after building (gatsby develop) and check /app

According to npmjs
The plugin gatsby-plugin-create-client-paths is deprecated.
https://www.npmjs.com/package/gatsby-plugin-create-client-paths
This plugin's functionality is now built-in to Gatsby.
Use the File System Route API: https://gatsby.dev/creating-client-only-routes.
This package will no longer receive updates.

Why angular2 sources don't have typescript files in sources [duplicate]

When I work with angular2 code I often need to see the implementation of a class, let's say the Router class.
If I click on the Router type in my IDE WebStorm, e. g. inside the constructor of another class
export class myClass {
constructor(private router: Router) {}
// ...
}
my IDE takes me to the TypeScript definition file router.d.ts inside my node_modules folder. What I want is it to take me to the original router.ts file with the implementation of the router class, not just its definition.
The original .ts file is not included in the node_modules folder structure when you get angular2 from github via the standard package.json suggested in the Angular2 Quickstart. Currently, I have to look up the original code in the official github repo.
Any ideas how to get the .ts files into my node_modules/#angular folder instead of the .d.ts files?

Sadly, it's not possible since no TS files exist. Even if you add them it still not possible since you import real angular paths which always point to the definition files. On top of that the file structure of the project does not correlate to the structure of the import string literals.
Some background and more information
The NPM package does not include .ts files, this is by design from the angular team. Up until some time ago the .ts files were indeed supplied with the NPM package.
The reasoning for removing them is to disable abuse from users accessing private classes and #internal and private APIs which is public methods/properties in the API that are not supposed to be public but must be so other angular internal classes can use them.
We used to see a lot of code samples out there doing things like import { PromiseCompleter } from 'angular2/src/facade/lang'; (before RC0) but this was changed when the project structure had a big structure refactor in RC0. This abuse was wide and it's bad, very bad... For users and for Angular PR.
The Angular project has a complex and robust build process where all of the API is moved from .ts files into d.ts files using an automated process that limits exposure. (public_api_guard)
The end result is d.ts files only.
It's also not possible to clone the git repo and use it since, again, the file structure is way way different so imports will have to change. Most importantly without the build Angular will, most likely, not work.
A solution using a different approach
However, if you debug your app you notice that you reach actual angular core .ts files in the source view of the console, this is because the NPM package comes with source map files that include the whole TS source code. Nice trick they did there.
This is what I use to dig deep into angular, it works quite great and I get a lot from it.
It's not as nice as Goto Declaration but it something...
IMO it's also easier to understand when you step through code...

How to organize angular module dependencies

I use the application component segmentation logic when creating my angular application, which is to say I have the following folder structure:
app.module.js
app.config.js
components
---- core
-------- core.module.js
-------- etc...
---- component1
-------- component1.module.js
-------- etc...
---- component2
-------- component2.module.js
-------- etc...
---- etc...
shared
---- sharedComponent1
-------- etc...
---- etc...
assets
Now, I group all my components into my app.module.js file and that's pretty much all that file is there for. My component1.module.js will list dependencies that module requires and so on. Now, I realize that it sort of doesn't matter where I define module dependencies and that I can put all my dependant module, regardless of component in the app.module.js file, but that's simply not clean nor does it offer good modularity.
That being said, I'm not sure what to do with modules that are used in every, or almost every other module, like modules for localization for example. The real problem here isn't that the whole app uses that module, it's that that universal module needs to be configured, so I was thinking about putting that dependency, and the required configuration, in the core.module.js and core.config.js file, respectively.
I've read a lot about angular best practices, but I wasn't able to find something concerning module dependency organization which, I suppose, is because angular puts all the modules in a "big box" anyway.
Another approach would be to create a shared component that focuses on incorporating that particular dependency, or group of dependencies into angular, and then have my other components depend on that component, but I'm not sure if this is too much.

I structure my modules as follows. The only real difference between my structure and yours is that all core/shared are basically the same thing. I have a component folder for each individual module of the application. Anything that isn't part of an individual component goes in core. The things that almost every single component use go in core too, as they are then a core piece of your application.
In my opinion, as long as you are breaking the application into components/angular.modules, keeping core code separate, and the organization is clear and easy to understand, its perfectly acceptable
core
----app
--------app.module.js
--------app.config.js
----util
--------util.module.js
components
----comp1
--------comp1.module.js
--------comp1.etc
----comp2
--------comp2.module.js

Why are there specific component.io libraries for jquery, jquery-ui, etc.

I've been looking into using component.io in a current project, as it seems much simpler than require.js and browserify, and I like a few things they've done.
Seeing as component.io doesn't require any component style wrappers, why does component.io have their own versions of jquery?
https://github.com/components/jqueryui
These seems to go counter to what they are proposing, as all component.io needs to know is the github username and project name in order to include the files.
If the only thing needed is the
"scripts": [
"ui/jquery-ui.js"
],
"main": "ui/jquery-ui.js",
tags in a component.js file, why not just have a component.js file which points to the main jquery-ui file?

as all component.io needs to know is the github username and project name in order to include the files.
No, that's not true
First of all - I think this should be clear before talking about component to avoid misunderstandings - component.io is only the website with a list of components using the package manager and build tool component developed by TJ Holowaychuk
'component' is ambiguous
Furthermore ComponentJS (http://componentjs.com) has nothing to do with it.
And also the component.json file in the context of bower has nothing to do with TJ's component. Bower renamed their component.json to bower.json and deprecated the old name
Nevertheless: some of the keys in bower's JSON are compatible to the JSON of TJ's component but that doesn't mean that a TJ component is build properly with a bower's component.json file.
To explain: No, that's not true you can read this form the componentjs/spec repository:
Components MUST provide a "component.json" file to describe the component's functionality and contents. Component developers MUST explicitly state the relevant file(s) via scripts, styles and others. [...|
To your question:
why not just have a component.js file which points to the main jquery-ui file
Usually someone can create a component.json file for an existing libarary like jQuery and send a pull request.
But the pull request might not be merged, because:
there is already a component.json for bower
the repository / build process don't contain/generate the needed files
project isn't maintained anymore
To be sure what's the reason in your case you can just ask at https://github.com/components/jqueryui/issues and/or
https://forum.jquery.com/developing-jquery-ui