One of the major “selling” points of Kotlin appears to be its ability to compile both to JVM or Android and to JavaScript for the web. To make use of this, it should be possible to have a code base where some files are shared between an Android App and a browser Web App.
However, so far I found little details on how such a thing would be set up, in particularly when working with Android Studio and its underlying Gradle setup, starting from a a run of the Android Studio New Project Wizard. I don't mind if I can only build the Web App on the command line, but I'd like to maintain the Android debugging hookups that Android Studio provides. So far I know very little about Gradle and typical idioms for its use.
I'm sure that I'm not the first person to have this idea, so I'd like to know some best practices on how to set this up. Questions that come to my mind include the following:
Do I mix the kotlin2js and the kotlin-android plugin in a single build file, or do I need to have multiple build files (perhaps I should say “modules” or “projects” except I don't know which)?
If I have multiple build files, should that be two (one Android one Web) or three (one more for shared things)?
If it is two build files, how do I reference the shared sources?
If it is three build files, which plugin(s) do I use for the shared one?
Do I need to split my sources over three different source trees? Are there any conventions how these should be called?
Do I need to split my classes into three groups of packages, or can code for different targets coexist in the same package?
What configuration settings do I need to tweak to make the IDE aware of the layout of my project?
I've read the following relevant documentation, among other:
https://kotlinlang.org/docs/reference/using-gradle.html
https://docs.gradle.org/current/userguide/intro_multi_project_builds.html
https://docs.gradle.org/current/userguide/composite_builds.html
https://kotlinlang.org/docs/tutorials/kotlin-android.html
I would recommend using IDEA wizard to create a simple multiplatfrom project for you (File -> New -> Project -> Kotlin -> Kotlin (Multiplatform - experimental) ). Community edition should suffice.
Answering your questions:
You don't mix plugins. You create a separate module for your common code and use 'kotlin-platform-common' plugin for it.
Three modules, special plugin 'kotlin-platform-common'
Use common sense for source splitting. Put whatever you want/able to reuse in the common code. Put platform-specific code in platform modules.
No package restrictions. You can put everything in the same package if you so desire =)
Pretty sure it should just work. If not, try re-importing.
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'm looking for a solution to have server settings in a config file of some sort separate from the JS app (which I could be running in dev or prod (built) mode) but allow for the server to replace the file with a new one at random point in time (when settings have changed) and allow the JS app to pick it up and refresh it's settings.
This is mainly for setting URLs to API endpoints.
My choice of JS framework is Angular 1 and 4 but answers geared generally towards various JS frameworks/libraries are applicable.
to have server settings in a config file of some sort separate from the JS app
If you are thinking about having your server settings exposed to the front you are gonna have a bad time ;)
I will assume that you think you will keep API URLs and maybe some config along with it in a separate file while you develop. Then I can advise two approaches:
1.) SIMPLE - Have a single JS file with a single object with all the necessary API URLs and settings in a tree like structure for organisational purposes. So you have a dev, a test and production property with everything in them. Once you load app 1st thing that should the app do is load the correct settings. This is fast and doesn't require any additional knowledge. Everywhere you had something configurable hard coded you replace it with a variable that derives from that file. This should suffice for simple applications.
2.) POWERFULL - For bigger applications with loads of different dependencies and more formal and professional approach do what most people do, use NodeJs, leverage Grunt or Gulp to help you version dependencies and write scripts for different builds. It requires you to install and learn to use new stuff but offers you way more power.
Even better combine this two approaches, link the external dependencies dynamically with the build and internal via including the correct JS file with all the API information.
You can also use other npm modules to assist you with your development like precompiling CSS, lint your code, rearrange and organise files by types into folders, auto-name files or folders.
Basically, MOST of the REPETITIVE tasks you do while developing can be automated this way. This truly shines on bigger projects when all this is handled by someone who is proficient and experienced with the 2nd approach, it can save months of repetitive tasks across the team.
You could use gulp (or even npm) as a task runner to do this kind of work. Maybe this article would help? https://www.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/
The main point of a task runner is that you can set a specific variable ie prod or development, and the task runner can then switch out your config files with the present definitions for prod or dev config.
/
..Common/Scripts/Script1.js
..Sharepoint2010/Layout/Scripts/[reference to Script1.js]
..Sharepoint2013/Layout/Scripts/[reference to Script1.js]
Developement for Sharepoint allows to deploy resources such as js and css files.
Different versions of Sharepoint have different metadata (project types, webparts, paths), but the source js/css are the same.
Programmatically it's best to have a signle copy of resource and use it from these different projects.
So editing Script1 in Sharepoint2010 project and saving it eventually result in updated Common/Script1.js which will be i.e. updated automatically for Sharepoint2013.
I'm relatively new to sharepoint, but I'm not searching for "use build options, cmd xcopy /sp2010/script1.js common/scripts/script1.js".
I'm using WebEssentials to simplify development, there are bundles, which defines path to resources and then compile these resources, but that doesn't work with the given scheme.
If I understood your problem correctly, "Add as link" option in Visual Studio can help you. The article is actually about Win8 development, but whatever.
I have been intrigued by the power and elegance that Opal offers in the way of using pure Ruby vs CoffeeScript or, of course, JS.
How would one go about leveraging Opal for Meteor as the primary language for development?
UPDATE: just wanted to share that we have shifted focus over to Volt for our realtime needs in an isomorphic environment that offers Ruby from bottom to top. It has been a fantastic experience and even Matz has tweeted about it a few times now.
I just released an initial version.
This will compile Ruby files to Javascript, but there is nothing meteor specific (yet).
I plan on porting Meteor to a Ruby class at some point, stay tuned or even better submit pull requests...
Yes, check out how the coffeescript package is implemented in Meteor in order to compile .coffee to .js. Specifically, the following
https://github.com/meteor/meteor/blob/devel/packages/coffeescript/package.js - The undocumented _transitional_registerBuildPlugin function which tells meteor how to turn coffeescript files into js files
https://github.com/meteor/meteor/blob/devel/packages/coffeescript/plugin/compile-coffeescript.js - The script that compiles files and generates source maps.
https://github.com/meteor/meteor/blob/devel/tools/bundler.js for how compiled files are served.
If everything is super well designed, you probably shouldn't have to touch the bundler to create a smart package that will build OpalRb files. However, I'm guessing that you are probably going to have to fire off a pull request or two to core in the bundler area in order to get it to play well with your package. Right now, the preprocessor treats all files individually, which may not be possible with your language (I'm not sure.) In the process, however, you'll be contributing to make Meteor's support of other JS dialects and compilers even better!
I'll reiterate my point that Coffeescript seems ideal if you want some sort of high level language for writing JS, especially since it supports in-browser source maps for debugging now.
Maybe a little late on the boat: I wrote a build plugin for Opal in Meteor.
You can find it on atmosphere https://atmospherejs.com/massimoronca/opal https://atmospherejs.com/mikamai/opal
You can install the plugin using
meteor add massimoronca:opal
meteor add mikamai:opal
Every file ending in .rb or .js.rb will be automatically compiled.
You'll have to wrap Meteor builtin Objects, until I'll release a package that does that, you can find a small example on how to do it in this gist https://gist.github.com/wstucco/42392ee21b76dfa3ef83
For example the Meteor global Object can be wrapped in Opal like this
class Meteor
def self.server?
`Meteor.isServer`
end
def self.client?
`Meteor.isClient`
end
def self.cordova?
`Meteor.isCordova`
end
def self.startup(&block)
`#{block.call if block_given?}`
end
end
and used this way
puts "Hello from server" if Meteor.server?
EDIT: moved the plugin under the Mikamai account
How can I (and what tools do I need to) create a makefile that:
Combine all JavaScripts '/js/*.js' (in a manual order - possibly with cat)
Verify that combined script works against unit tests (which using qUnit)
Minify JavaScripts
Verify that minified script works against same unit tests
I would like makefile to work on Mac OS command line.
I will be uploading the Makefile to a GitHub repository, so I would like something that other developers will be able to use easily.
Here is one complex script you could look for inspiration:
https://github.com/mobilizejs/mobilize.js/blob/master/release.py
(check also README)
Generally there are always project specific use cases and one solution does not fit every project, thus everyone is doing ad hoc scripts. Also, makefile is pretty limited in the end - I recommed to pick a real scripting tool.
Thanks for all the suggestions, here is the solution that I have decided to go with:
Makefiles - just as a shortcut really
Google V8 - to execute JavaScript from command-line
I can easily perform minification and unit testing using JavaScript.
I have made a few minor changes (added ability to write files) to the sample shell application that comes with V8 and compiled on OS X. I plan to somehow cross-compile for OS X and Windows in both 32bit and 64-bit. I will include binaries for V8 and custom application source in the GitHub repository. I will include instructions to obtain and compile V8 for those who want to customise or recompile.
V8 will be doing all of the work (essentially). Whilst I have yet to bring all of these things together, I believe that this should work.
The only downside is that DOM based unit testing cannot be automated. It might be possible to get the DOM stuff from the Chromium project, but this is probably going to be too time consuming. I'll leave that to an enthusiastic contributor (should anybody want to).