I'd like to know how to obfuscate a website build using the create react app project. (Rest assure the purpose for obfuscation is merely obfuscation itself and not any misguided sense of security).
Is there a way to use the popular uglify JS library in the build pipeline of the react app? How does it interact with various react features? What about dynamic imports? As of right now, there's almost no reliable literature on the matter anywhere else so I'm wondering if this can be done at all.
What about obfuscating CSS? (Random class names) Or is it possible to obfuscate generated HTML? (by randomizing div nesting)
UglifyJS is already a part of the react build process when you run 'react-scripts build'. You are able to disable sourcemaps when you run this build process, if you don't want others being able to read your code straight away, although it can be run through external programs into an easy to read manner.
If you want more control over the build/pipeline process, you will have to use a bundler. There are multiple out there such as browserify and webpack. Here is a short guide I found after a quick search. I hope this information helps.
Related
So I've started using VsCode over Atom recently and love it, the issue is I develop for software that uses its own JS API with no proper integration into anything.
I've started trying to implement my own autocomplete/intellisense structure using their pdf into VsCode to speed up my workflow, currently I'm simply using a JS file that is full of empty functions and objects with a bunch of JSDoc comments to help VsCode Intellisense identify what's what, that seems to be working fine so far but it means importing this "useless" file into every project I work on.
I looked into extending the JS language using a language server but that seems way too complex for what I need (plus it looks like I'd be building the entire Javascript language from scratch).
Does anyone have any recommendations ect?
Kind regards.
Edit
Sorry I also would like the ability for it to pass linting as right now it gets a bit funky with it.
You likely do not need an extension for that your example use case.
VS Code's intellisense for libraries is powered by .d.ts typing declaration files. The declaration files for the library you are using can either be written in your current workspace as you are currently doing, or—preferably—shipped with the library itself. Many npm modules ship their with typing definitions files, while other libraries have typing definition files provided by the community through DefinitelyTyped.
You alternatively bundle d.ts types file into as a separate npm package that you include in any project that needs them
I started using react as my ui framework of choice. Upon my adventure through the documentation I noticed that when using the create-react-app script to spin up a new react boilerplate, they used .js file extension on scripts that where returning jsx code. When I asked my buddy he told me that you should use the .jsx extension on scripts that are returning this kind of code.
Im a bit lost here as if both works, wouldn't it just be better to go with the .js extension as at the end of the day its javascript we writing.
Please help me with what is considered best practise. (I kinda have a feeling it would be to use the .jsx extensions on these types of scripts, but I'd love to hear the community's view on this)
Thanks in advance :)
It's really up to personal preference.
My personal opinion is JavaScript is JavaScript, and I just use .js. Others will prefer to use .jsx in files that are JSX and .js in for things like utilities, in order to differentiate. The only important thing is to be consistent in whatever you choose (at least within one project).
In general, it doesn't matter.
The only time it might actually matter is based on your build pipeline. Some build pipelines may be configured to compile .js and .jsx with slightly different rules, but that would be based on your application (things like create-react-app don't care).
At the end of the day, you could use a .cookiemonster extension and it'd work just fine (as long as your build pipeline is configured to handle it).
Actually it doesn't matter, is up to you to decide I prefer to use .jsx when I return the mix between HTML and JS and use .js only when I'm using plain JS or ES6.
I recommend you to read about this on this issue on github.
I'm creating a little SPA framework (might be a full-feature framework).
Frontend is based on native javascript (including ES6 features and web-components).
Backend is written in Go.
Here is a list of my needs, that I'd like to do automatically:
Minify my javascript files
Transpile ES6 code to ES5 (with something like babel.js)
Polyfill my web-components
Is there a way to achieve this without using node.js? Are there already go packages that can make those 3 things happen, with a "simple" grunt/gulp-like way?
I would like to avoid installing node.js, npm, bower... etc.
In my (not very classified) oppinion, using those node.js tools makes my application a mess adding a lot of unnecessery overhead to my application folder and makes my framework dependant on a lot of stuff (that application programmer has to learn, understand and know how to use).
Thanks for any tips/oppinions.
If you're doing a SPA you should just stick with gulp and others. You'll probably end up using npm stuff like browserify, autoprefix, etc, and you'll basically end up reinventing the wheel with your own asset pipeline.
With that said I've seen a couple, but none of them looked very mature last time I looked:
https://github.com/jbowens/assets
https://github.com/shaoshing/train
and you're going to need npm installed to use them regardless.
In order to build static web pages to serve interactive news applications (mostly data visualizations scripted with something like D3 or lightweight apps built with Bootstrap.js), is it worth the effort to install and configure a build system like Middleman or Grunt.js?
The reason why I am asking is because I am not familiar with Ruby and Ruby Gems at all, and do not have the time and willingness at the moment to dwelve deeper into it, as I already know Python & Javascript pretty well.
Do I need to know Ruby in order to use Middleman productively? Or should I just use Grunt? I am asking because I want to reuse the same templates over and over again and heard that this is easy with Middleman.
There is a distinct difference between Middleman and Grunt.
Grunt is a generic task runner while Middleman is a static site generator.
Middleman for example would be used to create a site with multiple URLs. You put some files in a folder and Middleman takes care of arranging them, creating subfolders for URLs, rendering layouts, compressing assets and in the end you have a bunch of files that represent the site. All this is built in.
You don’t necessarily need to know a lot of Ruby to get started with Middleman, but to get the most out of it, understand how it works and change configurations to your needs, basic Ruby knowledge is key.
Grunt on the other hand works by using plugins and telling them exactly what to do. By default it does nothing. You could think of Grunt as "framework", ready for you to add tasks. Compress these two css files. Combine these JS files and move theme over here. Things like that.
For building a complete website I recommend Middleman. In order to be able to use the templates you create in another language like JS, you could use Jade as a templating language. By default Middleman uses ERB (part of the Ruby standard library). Another popular choice is HAML, but I’m not sure if there is a decent JS compiler for it.
If you want to have really fine grained control over the output of your JS files (you’re talking about JS client side apps in your question) you can even use Grunt and Middleman together. Grunt would take care of the assets (you can have really detailed configurations there) and Middleman would handle templating, URL generation and all the other "default website related" stuff.
If you're keen to use Grunt as a base for this sort of build, you may like to look at Assemble.io.
This is a static-site generator like Middleman, but one that is completely (currently) dependant upon Grunt tasks in order to do its thing.
I believe the learning curve for Assemble.io is rather higher than Middleman. It is based on Node, rather than Ruby. However I don't believe it's necessary to know Ruby in order to get a lot from Middleman.
You may have a look to http://wintersmith.io/ a static page generator like Jekill or MiddleMan (I don't really know this one)
With Grunt you have something at a lower level: Grunt provides you tasks to automate things so you'll have to find or write the task that fits your needs.
So we're writing a full-text search framework MongoDb. MongoDB is pretty much javascript-native, so we wrote the javascript library first, and it works.
Now I'm trying to write a python framework for it, which will be partially in python, but partially use those same stored javascript functions - the javascript functions are an intrinsic part of the library. On the other hand, the javascript framework does not depend on python. since they are pretty intertwined it seems like it's worthwhile keeping them in the same repository.
I'm trying to work out a way of structuring the whole project to give the javascript and python frameworks equal status (maybe a ruby driver or whatever in the future?), but still allow the python library to install nicely.
Currently it looks like this: (simplified a little)
javascript/jstest/test1.js
javascript/mongo-fulltext/search.js
javascript/mongo-fulltext/util.js
python/docs/indext.rst
python/tests/search_test.py
python/tests/__init__.py
python/mongofulltextsearch/__init__.py
python/mongofulltextsearch/mongo_search.py
python/mongofulltextsearch/util.py
python/setup.py
I've skipped out a few files for simplicity, but you get the general idea; it' a pretty much standard python project... except that it depends critcally ona whole bunch of javascript which is stored in a sibling directory tree.
What's the preferred setup for dealing with this kind of thing when it comes to setuptools? I can work out how to use package_data etc to install data files that live inside my python project as per the setuptools docs.
The problem is if i want to use setuptools to install stuff, including the javascript files from outside the python code tree, and then also access them in a consistent way when I'm developing the python code and when it is easy_installed to someone's site.
Is that supported behaviour for setuptools? Should i be using paver or distutils2 or Distribute or something? (basic distutils is not an option; the whole reason I'm doing this is to enable requirements tracking) How should i be reading the contents of those files into python scripts?
The short answer is that none of the Python distribution tools is going to do what you want, the exact way you want it. Even if you use distutils' data_files feature, you're still going to have to have your javascript files copied into your Python project directory (i.e., somewhere under the same directory as your setup.py.)
Given that, you might as well just copy the .js files to your package (i.e. alongside mongofulltextsearch/init.py) as part of your build process, and use package_data or include_package_data=True.
(Or alternatively, you could possibly use symlinks, externals, or some such, if your revision control system supports those. I believe that when building source distributions, the Python distribution tools convert symlinks to real files. At least, you could give that a try.)