From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 5867E7EF10 for ; Wed, 25 Feb 2015 06:58:26 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of jordojw@gmail.com) identity=pra; client-ip=209.85.217.180; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jordojw@gmail.com"; x-sender="jordojw@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of jordojw@gmail.com designates 209.85.217.180 as permitted sender) identity=mailfrom; client-ip=209.85.217.180; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jordojw@gmail.com"; x-sender="jordojw@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-lb0-f180.google.com) identity=helo; client-ip=209.85.217.180; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jordojw@gmail.com"; x-sender="postmaster@mail-lb0-f180.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BtAQD/Y+1UlLTZVdFbg1VaBIMEwByFdAKBIQdDAQEBAQEBEAEBAQEHCwsJEjCEEAEBBBIRHQEbHQEDDAYFCwMKAgImAgIhAQERAQUBHAYTIod4AQMRDa5xPjGHYoNMgWuCd45BChknDQxIhF0BAQEBAQUBAQEBAQEWAQEEDoETiXKCRIIqB4JogUMFik6IbYIWAQWCA4FGgRuMGYJJgXQSI4EMCYJUgV0dMYJDAQEB X-IPAS-Result: A0BtAQD/Y+1UlLTZVdFbg1VaBIMEwByFdAKBIQdDAQEBAQEBEAEBAQEHCwsJEjCEEAEBBBIRHQEbHQEDDAYFCwMKAgImAgIhAQERAQUBHAYTIod4AQMRDa5xPjGHYoNMgWuCd45BChknDQxIhF0BAQEBAQUBAQEBAQEWAQEEDoETiXKCRIIqB4JogUMFik6IbYIWAQWCA4FGgRuMGYJJgXQSI4EMCYJUgV0dMYJDAQEB X-IronPort-AV: E=Sophos;i="5.09,643,1418079600"; d="scan'208";a="123268570" Received: from mail-lb0-f180.google.com ([209.85.217.180]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 25 Feb 2015 06:58:25 +0100 Received: by lbiw7 with SMTP id w7so1602548lbi.10 for ; Tue, 24 Feb 2015 21:58:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4RPKno6CVFYlldarT7K2ZWSkW82EX4YI2lq9QeUg3DM=; b=w8LkSGQqUexEYD7lBnj5/QH8a/CZ4noFHUxie+5/1+muXwtpMx1LokKNA2J9CnG3ik aAgbcA5q05cqKI7KZeJk50SQehjp9Qy88uKFKZdlaR/+A1/qAh+BkXOXomXVk69QESE1 acf38mlnxHwnPMfNwl43jjmEQ+oHkgg77MGgViCpmxxPhaugI3vjlulr2OmIol7QSHnZ J2zh4yCCPs9I/VCUSlaTUk7inUrCITjagero4Oy2FEZMTWaGhLgPjmez5dy5HVevC4Xs +u+Vfoq/Ro/a9bhdwkP+MakjySeUn+Q1sgOtFSrBzYVAHmxxUgjAeB0RPFUyj7rfzuGG G2zg== MIME-Version: 1.0 X-Received: by 10.152.182.196 with SMTP id eg4mr1286898lac.70.1424843904817; Tue, 24 Feb 2015 21:58:24 -0800 (PST) Received: by 10.25.128.3 with HTTP; Tue, 24 Feb 2015 21:58:24 -0800 (PST) In-Reply-To: References: Date: Tue, 24 Feb 2015 21:58:24 -0800 Message-ID: From: Jordan W To: Andrew Herron Cc: "caml-list@inria.fr" Content-Type: text/plain; charset=UTF-8 X-Validation-by: jordojw@gmail.com Subject: Re: [Caml-list] CommonML: An opinionated build/package/develop workflow on top of CommonJS There's certainly a lot of ideas/experiments in CommonML all rolled into one. The overarching goal was to just explore the ideal developer flow for people who are either used to CommonJS or who appreciate a highly sandboxed development model without globals. There's some "pointless" goodies thrown in like zero effort merlin support and automatic doc generation (which is now being solved in a *much* better way by other people more knowledgeable than myself). CommonML is just a hacky script, but I find it useful to build developer tools by starting with the ideal end developer experience and performing whatever atrocious hacks I have to in order to create it. After I get feedback, I can explore doing it the right way. Obviously OPAM is the real deal, and I hope some people can help me achieve much of this with OPAM (as it is, or in future versions). But the most valuable part of the CommonML experiment, actually has nothing to do with package managers/sandboxes at all - it's the automatic namespacing of dependencies (using module aliases) and automatic generation of merlin completion files. You literally only have to list a new dependency in your `package.json`, then it will resolve all naming conflicts, build correctly, and allow you to immediately start autocompleting using merlin. I suspect such a seamless experience is only feasible when there are opinionated conventions in place. I feel like most people would be satisfied with the ones explored in CommonML: - namespaced dependencies, non-namespaced internal modules (ModuleInsideMyPackage.x, YourPackage.ModuleInsideYourPackage.y) - powered by module aliases. - "exports" field in `package.json` that determines which modules should be publicly available to other packages that depend on you (nothing is visible to other packages by default). I don't know enough about the OCaml build toolchain to solve this in a scalable way so I made it work generally enough for a couple of the projects that I'm prototyping. I hope the same can be achieved in some other more sophisticated build tool. Has anyone seen anything like the automatic namespacing I've prototyped here? I couldn't imagine developing without it, personally. On Tue, Feb 24, 2015 at 7:12 PM, Andrew Herron wrote: > I've been thinking about this a bit, as a JS developer who is experimenting > with OCaml (in my non-existant free time). I don't use the CommonJS flow in > my day job although we do have many projects which our internal > build/dependency system combines with similar results. > > > On Wed, Feb 25, 2015 at 6:26 AM, Jordan W wrote: >> >> >> I created a proof of concept called CommonML, which lets developers use >> their familiar CommonJS workflow with OCaml: >> https://github.com/jordwalke/CommonML > > > My initial thoughts were to stick with the OPAM repositories; even if I have > to make a local OPAM repo server it seems like leveraging the existing > ecosystem is a good idea. My experiments use a dedicated `opam switch` for > the project, enforced by the Makefile (which might not scale to multiple > projects, but I haven't tried that yet). > > I can think of one good reason to share OCaml and JS dependencies on the > same server though, and that's including a JS library in a js_of_ocaml > project. Certainly using a single package.json file to specify both JS and > OCaml dependencies is an interesting idea (even if under the hood we > eventually find a way to use OPAM for the OCaml projects). > > Cheers, > Andy