How to obfuscate code in Vite's library mode - vite

I've built a project with Vite. I started from the vanilla TypeScript template. When I created a web page all of the JavaScript code was heavily minified and obfuscated. I did not have to ask for this; it was on by default. However, when I turned on Vite's library mode, my JavaScript is readable again.
Is there a way to make a library build and have it obfuscated and minified?

Minification is purposely disabled in lib mode for the es format because it breaks tree-shakability of the output. Vite only obfuscates/minifies the non-es formats (e.g., umd), and there's no config to override that.

Related

is it required babel configuration when I use vite in place of webpack

Recently I was create react app using vite , it is lightweight , less config and fast then compare with webpack . now my question is , is it required bable configuration in Vite project
No, vite does automatic syntax transforms but it only targets browsers that support es modules (firefox & chrome started supporting it around 2018). If you want to support new js features in older browsers you need to add polyfills though. You can read about the exact behavior and how to support even older browsers here.
I think that question need more information about that topic.
Vite.js uses the built-in JavaScript support of the browser, so you don't need to explicitly configure the JavaScript version in Vite.js itself.
When I said Vite.js uses the built-in JavaScript support of the browser, I meant that Vite.js relies on the JavaScript engine of the browser to interpret and run the JavaScript code in your application. The JavaScript engine is the component of the browser that executes JavaScript code. When you visit a web page that contains JavaScript, the browser runs the JavaScript code using its built-in JavaScript engine. This means that the version of JavaScript that is supported by your application is determined by the version of the JavaScript engine that is built into the browser. In the case of Vite.js, the JavaScript code in your application is not transpiled or otherwise modified before being run by the browser. However, if your application uses modern JavaScript syntax that is not supported by the target browsers, you will need to transpile the code to an older version of the language that is supported. In that case, you can use Babel.
No, it is already setup on the background. However if you'd like to adjust Babel's config you can do it. Read the docs here: https://github.com/vitejs/vite-plugin-react/blob/main/packages/plugin-react/README.md

Neutralino - Obfuscate resources file?

Is there some way to Obfuscate the code that is inside the resources.neu file?
It can be read in any text editor... it contains the CSS HTML and JS content.
Not a big problem but can it be done?
Thanks
The .neu file is generated when you build your neutralino app, so you should obfuscate your source files first, and only then, build your neutralino app. The generated .neu file will contain the obfuscated code. To obfuscate your code there are a few solutions available, but Jscrambler seems to offer the most complete suite.
As of January 2022 Neutralino Uses Electron's Asar Format to bundle all the files together at one place which can be easily uncompressed using the same tool.
You can use code Bundlers like ES Build or Webpack which will bundle and minify your Code and your bundled code is pretty much unreadable.
For Webpack there is a plugin Webpack Obfuscator which can be used to obfuscate your code even more.

Why webpack and babel are dependent on Node.js to run?

I was learning babel and webpack and then it turns out I need to install node.js to run them both and I asked myself WHY? Then according to my research, we need node.js for webpack and babel since both of them were written in JS and to run that JS code which transpiles( for babel) and bundles up the code(for webpack). Also, another reason is that since both babel and webpack handles our JS code outside of the browser, this is the reason to use Node.js. Are these reasons true?
According to the Node.js website -
Node.js® is a JavaScript runtime built on Chrome's V8 JavaScript engine.
Webpack and babel (along with many other tools you might use for frontend development) are written in javascript and since they are command line tools, they need a way to run outside of the browser (directly on your machine).
They could have used some other language to write the tools but since they chose to write them in javascript, Node.js is the only feasible options right now.
In case you are interested, the original creator of nodejs
Ryan Dahl has built another secure runtime environment for Javascript/Typescript called Deno
Yes, at the moment the node.js project is non-portable by full open source disclosure nor extension to port node.js commonjs without a just in time transpiler with a service worker on a server.
Definitions: FHC = "from half court"
Babel and webpack
(1) transpile/move (write&read, not ln -s sym...bolic link) & (2) compost/pile onto a JIT target,
like v8 or other browser-javascript-interpreters. v8 on a service worker can compile on the edge just in time for interpretation in a browser v8 environment but still on the cloudflare edge server.
Declare (FHC) Allegedly, rust provides webassembly modules with the lipid [llvm-]wrappings
that nucleic acid exocytosis needs to be a full-blown virus, err I mean
Initiation Routine needs to be a targetable JIT extension!
A compiler/transpiler still requires it's target-scope receivable. Declare (FHC) Emit is to execute as compile is to interpret, even AST.

Debugging ServiceStack’s react-lite and vue-lite

How can I attach a debugger to debug the typescript part (react/vue) of the new “lite” templates?
For regular SPA projects with npm there are two ways I know of:
either debug from VSCode - run SS and npm start and then attach to Chrome
debug within Chrome, as the typescript source maps are available somehow
With the new “lite” templates debugging the server-side is easy, but what to do with Typescript/React/Vue debugging? I tried to run SS from command-line, and then attach VS Code to port 5000, but the breakpoints won't hit (not even for the compiled JS files)
There’s no source maps support in the Vue/React lite Project Templates so you won’t be able to debug the original .ts source files and you’ll need to debug the bundled .js instead from Chrome’s WebInspector.

using browserify output bundles directly in node.js

Ok, so modules written for node.js can be combined into bundles with browserify.
But just in case I only have a bunch of bundles created by browserify and not the source, would it still be possible to 'require' or otherwise use these bundles and their contents in a node.js environment besides the browser? (granted that the code does not do anything browser specific)
Ok, so modules written for node.js can be combined into bundles with
browserify.
Firstly I am not sure what you mean by this, as browserify was created to do the opposite. Browserify was made to allow the use of node's require() statements in the browser.
But just in case I only have a bunch of bundles created by browserify
and not the source, would it still be possible to 'require' or
otherwise use these bundles and their contents in a node.js
environment besides the browser? (granted that the code does not do
anything browser specific)
Yes in short, as long as the modules do not use the global window scope because window is undefined in node.js. Common helper packages like lodash, axios, moment, bluebird, and q promises all work in node.js.
Generally though, packages are often modified to work in both the browser and node.js. There is a browser attribute option in package.json files that allows you to specifically target the browser when publishing npm modules. Often files designed for the browser are minified down to one file because of how files could potentially be imported into the browser. This is not necessary with node and there may be many files in a node project.

Resources