I've been going through the documentation at https://bazelbuild.github.io/rules_nodejs/ in order to put together a small web based application. I've got babel building the JS code, and http_server serving it, and ibazel watching it, and everything is working as expected: when I make a change, ibazel notices it and restarts the http_server rule.
The next thing I wanted to look at is getting autoreload in the browser so that the browser would automatically refresh when the change was compiled. My understanding is that this requires the http server to not be killed by ibazel, but instead to stay up and trigger a refresh via the ibazel_live_reload mechanism. I believe that http_server doesn't support this, but ts_devserver is explicitly mentioned in several places. However, ts_devserver doesn't seem to be maintained anymore (although I did find a devserver EXE in the npm package, there isn't a bazel rule that I saw to use it).
Is there a third party live development server that supports the ibazel reload mechanism - or am I missing something completely obvious?
Disclosure, I'm a core maintainer on rules_nodejs
As of rules_nodejs v3.0.0, ts_devserver has been renamed to concatjs_devserver to try and better namespace it (it has little to nothing really to do with Typescript). Its docs can be found here.
Note though that the concatjs_devserver comes with some compatibility gotchas, all dependencies have to be in named AMD/UMD or goog.module format for example, and may be tricky to use unless following the rest of the google3 toolchain.
We've (as the maintainers of rules_nodejs) tried not to wrap an existing devserver and publish it as of yet for various reasons, but it's something that has come up in discussion. I'm currently investigating some options in this space.
I'm not aware of any published devservers that currently support the ibazel protocol, there is a wrap of browsersync in the Angular Components repo which you may find useful.
Related
I set up a GitLab self-hosted instance and its working fine, my problem right now is that I don't really understand how the frontend works. Mostly because I've been focusing on the backend and because I couldn't find documentation about it either. I wish to understand how I can comment out things I don't want to show for the user or in the overall design, change aspects and text, and overall have control of the frontend.
I'm running on Debian 9, the setup was made with Bitnami using Google VM. As far as I understand I have to manually change the files I want, but I really don't understand the structure of this type of frontend.
What language do I need to know here and where should I find the documentation, how to find the correct directory and files, etc.?
While GitLab doesn't officially support any type of "custom frontend", what you can do is:
Fork GitLab
Use the GitLab Development Kit to implement your changes
Run a Source Install of your fork
The frontend is mostly written in HAML (for the server-side bits) and Vue.js (for the client-side bits).
Note: Even an Omnibus install copies raw ruby and javascript files somewhere, and since they’re physically on the system, they can be manually manipulated and hotpatched, but that’s not really a sustainable way of introducing changes to the codebase.
I'm currently working on an IPFS/Ethereum dapp in Muon.
Because i need Metamask i started with this Boilerplate: https://github.com/SwapyNetwork/electron-metamask-boilerplate
Everything is working fine so far.
However i can not use require('anything') in the renderer process or in html script tags. (See below)
There seems to be a problem with the boilerplate code but i can't find it.
Or is node code in renderer not supported in Muon?
My only change in testing is setting node-integration explicitly to true and
inserting require('fs') in index.js. (i installed fs of course).
I tried many different solutions from stackoverflow and other sites but couldn't find a solution yet.
Error Message
Thank you
As per the muon's github repo:
Some of Muons goals include:
Use the Chromium source directly (eliminating electron's copy of chrome_src) with minor patches
make integrating chrome components less painful
faster and more streamlined end-to-end build process (see browser-laptop-bootstrap).
add support for Chrome extensions
add security focused features for the renderer:
remove node completely (from the renderer process)
full sandbox
scriptable window.opener support
As you can see there, muon does not supports node code in the rendered. It is by design for security purpose. Muon may be great for certain applications, but I recommend switching on to electron if you really need to use require in the renderer.
So, here's the situation. I've recently "inherited" a decent sized web application, built using React (and Redux) and compiled using webpack/babel. Two files are generated, app.js and server.js, both of which run on Node.
The original developer of the project was mostly "winging it" on the back-end (server.jsx and so on -> server.js), using console.log to figure out what was going on, and then just gut feeling the fix. That works on a smaller scale, but will be problematic in time.
I can debug both of the actual files, but only app.js is ever mapped properly, meaning I can debug the source code. This also affects hot loading. Any breakpoints related to server.js will only trigger in the actual server.js file in IntelliJ, which is a completely unreadable mesh, so that's not really an option.
I'm using IntelliJ (WebStorm for those of you who only use the web version), and I've tried to use every single guide I've come across to set it up, which usually comes down to babel-node, babel watchers or webpack-dev-server. The current app.js is run using webpack-dev-middleware, and debugging it in Chrome works like a charm, but for some reason it always just bundles in server.js and then fires when ready (in these Star Wars times).
I understand that it's hard for Chrome to get access to server.jsx, but surely there must be some way of setting up IntelliJ (or WebStorm) to do so? I'm more used to a Java or C# server side, so I'm a bit baffled that this isn't a straight forward, out-of-the-box option. Or maybe it is, and the initial setup is lacking?
PS. When using React (and Redux) as both the front and back end on Node, is it meant to be virtually impossible to distinguish between the two? Server.jsx is fairly obvious, but there are quite a few duplicated javascript files and dependancies, especially related to handling/building the Redux store.
I create a web server with Sails.js, and want to allow third dev to create node.js plugins installable from a web page (store).
My problem is I don't want this plugin to require sails (or other critical modules) and have access to database and services and do what they want.
For example using fs and delete all files.
How can I do that ? I have no idea if node.js can lock some scripts on this own directory
I don't think that node expose some sandboxing functionality so when you load a js code into node that code can do what it want.
From your description yours plugins are more like browser javascript code so I think that you can use a headless browser to execute your code and retrieve the result. I've never tried it by myself but it should work. You just have to figure out how to pass parameters to plugin and get the result, also performance will be very bad because the headless browser is quite heavy. Try looking at
http://phantomjs.org/
Another solution is to run the plugins directly inside node but sanitizing the code before running. There are some projects like:
http://gf3.github.io/sandbox/
https://github.com/asvd/jailed
They can help you limiting the powers of the plugins.
Anyway are you sure about it ? in any major CMS platform that I've seen (wordpress, joomla, drupal, liferay ...) the platform's author trusts plugins authors and plugins can always do what they want.
Part of this problem might be that there's too much discussion on the client side for me to see wood for the trees.
Anyway, here's what I want to do. I need a platform independent server-side implementation of WebSockets. I'd like it to run in NodeJS.
Now, 99% of what I've found on this topic talks about socket.io. But so far as I can tell, that is not WebSockets, it's a special "extra" protocol in its own right. I need something that works "by the (not-yet) standard". There's a good reason for that, and it's non-negotiable, trust me on that.
So, I tried WebSocket, but that requires (or appears to require both python and, worse, Visual Studio) to run on Windows. I need something that is platform independent and doesn't need special things like this.
I also tried node-websocket-server, but I can't get that to work at all. The example on the main page fails for me. It seems to accept a connection, but the client doesn't see it, neither side gets to send anything, and the client immediately sees the connection as closed. Indeed, all I ever get is a "connection" callback, and then it seems to die. Running in debug mode didn't tell me anything useful, except for some internal error about some object or other not having a flush() method. I half-suspect this is a defunct project?
So, I'm out of ideas. Is it possible to persuade socket.io to work purely by the (non)spec for WebSockets? Is there a way to get node-websocket-server to behave that I've failed to find. Is there a way round the Visual Studio dependency in websocket, or is there some other NodeJS based tool that meets all my requirements?
Oh, one other thing, I'd like the tool to coexist peacefully with "connect" as I'm using that for my regular document serving.
I had the exact same problem that you're facing at the moment when I tried to use Socket.IO on a different platform without a direct port of the client (and without the motivation to port it myself).
I ended up moving my code to use ws which is a standards based websocket implementation for node without the added sugar from socket.io.
It works extremely well in my case over several different platforms but you would need to rework most of the connection/reconnection code etc.
Website : link
GitHub : link
NPM : npm install ws
Socket.io uses WS under the covers so you may hit the same installation issue on Windows. You may find that it complains that you need to install Visual Studio 2010 for the ws component to work.
However, you can configure the version of Visual Studio used by node-gyp that runs the C++ compiler via an environment variable.
Examples:
set GYP_MSVS_VERSION=2012 for Visual Studio 2012
set GYP_MSVS_VERSION=2013e (the 'e' stands for 'express edition')
For the full list see
- https://github.com/joyent/node/blob/v0.10.29/tools/gyp/pylib/gyp/MSVSVersion.py#L209-294
This is a painful for Windows users of NodeJS as it assumes you have a copy of Visual Studio installed which many non-dev end users will never have. So I'm lobbying Joyent to the encourage them to include web sockets as part of CORE node and also to ship a GNU gcc compiler as part of NodeJS install so we can permanently fix this problem and not have to force Windows node users to tweak their environment or download anything else.
Feel free to add your vote at:
https://github.com/joyent/node/issues/8005#issuecomment-50545326
NOTE: The Joyent team have indicated that socket.io will fall back to using a slower implementation when compiling ws fails. In other words your code will still run - just not as fast. This is not clear for end users performing an install of any app that depends on socket.io or ws as it display red error text during the install process leading users to assume that the install failed, when in fact it will work albeit slowly.