Support yaml/json

Opening this issue to get the discussion going -- xml is very verbose. Many project nowadays opt for configuring using YAML or json.
It would be great to have support for those in msbuild.

I don't believe yaml is in fact markup, but I'm all for json... Much clearer.

json +1

json +1 here

json +1²

JSON would be totally in spirit of the "new" .NET

I'd be curious how a json formatted MSBuild project file would play with AspNet vNext's project.json.

json support will be great of course after getting msbuild xplat

One important bit about json config is the (lack of)  comments,which are useful in a build configuration. How would json support that?

@hmemcpy the fact that official JSON standard doesn't support comments doesn't mean a thing. JS comments can be easily handled by a JSON parser.It doesn't need to be "Crockford's valid JSON", you know.

I think it would be helpful if someone converted an existing MSBuild solution (e.g. this repo) to json so we can see how it looks like :)

Without being for or against this suggestion, the main thing we would need to keep in mind is alignment with Visual Studio and the project files. It's something we will definitely bring up for Visual Studio vNext, but I'm not sure that we would take a change right now for the current MSBuild incarnation as it would likely be fairly substantial.

:-1:
Unless someone plans to write a JSON 'schema validator' this will not happen. XML has all that built in.
A better choice would be some JSON to MsBuild XML preprocessor task. Well anyone can do that, it does not have to be built into MsBuild.

@leppie
JSON Schema and Schema validation is a thing. See ASP.NET's project.json:
https://github.com/aspnet/Home/wiki/Project.json-file

@ChaseFlorell YAML stands for Yet Another Markup Language.  And YAML can have comments :-)  And it is way more readable than JSON.

YAML is a superset of JSON, so I'd rather see support for YAML (which would thus automatically include JSON support unless YAML-specific features like multiple documents in a single file are required). YAML is also a lot easier to hand-modify in case that matters for people (comes up for me very occasionally where I need to manually edit a .csproj because I accidentally did something derpy in VS that I couldn't fully revert).

@darrelmiller, I know what it means, but it's not really 'markup'. Just my opinion, but I'm not a fan. Invisible characters have no place as deliminators. Json support on the other hand aligns nicely with the vnext direction.
Also, extra data inside json wouldn't affect its purpose, so comments can easily just be extra data. When parsed, comments show up as properties.
{"_comment":"I'm a comment. "}

@ChaseFlorell I deleted my comment because I was wrong about what YAML stands for  :open_mouth:
Anyway, I realize the momentum is going to be behind JSON, but having worked with both, I personally find YAML so much more pleasant.

  But I would LOVE to see MSBuild support Xaml.  Xaml already has built-in support for designer support in VisualStudio, and has rich tooling support for intellisense through add-ons such as ReSharper.  Not to mention, it is used everywhere in MSFT ecosystem these days (except ASP.NET, but I personally hope to change that as well. :smile:).    It's pretty pretty ubiquitous and should definitely be considered here.
Xaml is thought of as presentation markup, but it is an object definition language that can be used anywhere.  Again, it comes with built-in rich tooling support for free. As a quick example, here is a POCO that I've designed.  Along with its Xaml,  When I select the element with my mouse, this is what I see in the Properties Pane.
All for free, right now in Visual Studio.  If you have ever worked with Blend, then you know those controls are Blend designer controls and comes with all the designer/tooling support with them (for instance, that enum is a dropdown with all of its supported values).
Finally, by using Xaml, you get to take advantage of the one thing that nothing else in the entire world uses: MARKUP EXTENSIONS!  This is what makes Xaml so incredibly awesome and fun to work with.
I know some people find XML/Xaml as verbose, but I (and others) find it expressive and powerful.
I would LOVEEEE to do this with MSBuild!!!

Some additional considerations as well:
XML was intended and designed to be language-agnostic.  I know that JSON is the new, shiny kid on on the block, but it violates this principle this just by its very name.  Also, the magic schema it is using is (in my view) suspect, as it introduces dynamic (unstructured) properties that may or may not be consumed/understood by its consumers, possibly causing inadvertent side effects.  Finally, this is nit-picky, but it also introduces unnecessary overhead to the file, which flies in the face of its "lightweight/optimized" value proposition.
Furthermore, when using the current JSON schema mechanism, it references another artifact that lives on the system somewhere.  So now, from a tooling (and management) perspective, we have to account for 2 artifacts instead of one.  This is exactly how the .NET configuration mechanism worked and it was a burden to work with (even more so as it required you to create configuration mapping items altogether to map between the POCO and configuration elements, but I digress).
Using the a class definition as the schema (as Xaml does) is the way to go, as you only end up dealing with one artifact and all tooling is done from there (the class definition).  Once JSON effectively does this, then I feel it can start to be considered as a legitimate object definition "markup" (please kindly recall that JSON is actually code) language.  But then, at that point, it's being exactly like Xaml... so why not go with the option that has the more history/maturity and (most importantly) tooling support (this is what makes us efficient, after all!).
... and then there's that whole language-agnostic thing... oh, and markup extensions. :)
I'm not trying to start a JSON vs Xaml fight (ok, maybe a little :innocent:), but I am trying to make sure all points of view are considered here before we all go chasing the new shiny toy.  Some of us have been around a while here and there are reasons why we do the things we do... so it's good to discuss these things and get them out and have all points considered. :)

I actually like the idea of XAML over JSON.  If I had to write MSBuild configurations in JSON, I would probably want to jump out a window.

@Michael-DST

XML was intended and designed to be language-agnostic.

From json.org: "JSON is a text format that is completely language independent." (In fact they are both their own languages, hence the L in XML; but they are markup languages rather than general purpose languages.)

Also, the magic schema [JSON] is using...

Not sure what "magic" you are talking about. Just like XML, JSON can be schemaless, or it can be tied to a schema.

it also introduces unnecessary overhead to the file (in that it introduces data into the file that is intended to only be known by designers...

Not sure what you are talking about here; what "designers"?

Furthermore, when using the current JSON schema mechanism, it references another artifact that lives on the system somewhere. So now, from a tooling (and management) perspective, we have to account for 2 artifacts instead of one... Using the class definition as the schema (as Xaml does) is the way to go, as you only end up dealing with one artifact and all tooling is derived from there (the class definition).

In both cases, there is a schema definition that lives separately from the markup; in XML/JSON its a schema file, in XAML its a class, but there are no fewer artifacts to deal with by using XAML. (Not to mention, doesn't using a class for the schema definition destroy the "language agnostic" characteristic you were advocating for?)

...please kindly recall that JSON is actually code...

No, it's not. It may have started out that way, but [json.org](language definition for JSON) clearly specifies that only objects and scalar values are valid; arbitrary expressions are not allowed.

...why not go with the option that has the more history/maturity...

Xaml may have more history, but JSON is and will always be more widely supported in the software industry (and the same is true for XML). I don't know that I want a new developer to have to learn XAML AND MSBuild just to understand how our build works (see my following comment on build DSLs).

...and (most importantly) tooling support...

Tooling support - especially visual tooling, which seems to be what you are talking about - is definitely NOT the most important thing in a build tool. I value visual designers when they are appropriate, but a point-and-click designer for a build tool would just slow me down compared to a fast code editor with Intellisense.
The thing is, I am not necessarily opposed to XAML over XML for MSBuild. I used WPF heavily for several years, and really appreciated the power and expressiveness of XAML. But it is verbose, and it is complex, and there is a steep learning curve compared to most markup languages. XAML would have to provide significant benefits for the build system to be worth considering over XML, especially given that MSBuild needs to be approachable by any developer on any .NET project. In my opinion, you haven't provided any significant evidence of such benefits.

I think it is worth considering that markup is not the language of choice for modern build systems. MSBuild was created at a time when Ant, NAnt, and Maven were some of the most popular build systems. But today, Gradle, Rake, and Grunt are becoming the tools of choice, and for good reason. Build systems based on code rather than markup use DSLs to make doing the simple things easy, while making the hard things possible, without jumping completely outside of the build system to do them. My own hard experience with both MSBuild and Maven has shown me the pain that results from pretending that the build isn't a software system of its own. We should treat it as such by using the best tools we have available for building software.
My opinion is that the best option for a new language for MSBuild would be the new C# scripting abilities being built into Roslyn.

I would not be against MSBuild allowing C# like scripting for builds, especially along the lines of something like Bau or Cake.

Cool.  Thank you for the discussion @eatdrinksleepcode. :)  I knew I was gonna rile someone up after I posted all that... I almost deleted it haha.
To start with, when I say language-agnostic, I mean it is agnostic from any other language from itself.  JSON's (original) intent is to be consumed by a JavaScript or JavaScript-aware client for serialization/conversion into a JavaScript application.  I realize it can be used in any application, but I am just looking at it from the perspective from other non-JS languages.  To me, it's about the equivalent as seeing a VBON (VB) or CSON (C#).  Sure, those would make sense in their two respective paradigms, but outside, of it... well, that's where we run into this area.  (To be sure, I am not saying those exist... but just saying that's what it is like.)

Not sure what "magic" you are talking about.  / Not sure what you are talking about here; what "designers"?
More succinctly, the consumers of the file format that provide design-support.  In this case, MSBuild (or Visual Studio).  When I say "magic" I am referring to the "$schema" attribute.  If I understand correctly, this points to another artifact altogether to that is the schema to describe the data, correct?  That means that 1) someone somewhere has to create that artifact at some point and 2) know where it is and reference it in their file.  The schema in Xaml is inferred from the class itself, so there's no other external artifact than the current file that you need to worry about.  That makes it easier to create/manage/maintain/etc.

Not to mention, doesn't using a class for the schema definition destroy the "language agnostic" characteristic you were advocating for?

Xaml is also still language agnostic in this case, as the class it is pointing to could have been compiled as C#, or VB, or even F#.   That is what is (one of the many things) awesome about it, IMO. :)

Tooling support - especially visual tooling, which seems to be what you are talking about - is definitely NOT the most important thing in a build tool.

Well, I am not so sure about this.  There is so much to be done in this area, innovation-wise.  But at this point I am mostly talking about intellisense.  And the intellisense with Xaml (especially with ReSharper) is so much better than what is offered with Xml and JSON (at the moment, I'm sure it will get better).  The fact that so much has been done around its format in Visual Studio for presentation tooling (in WPF, etc) makes it all the better (again, I think there is so much innovation left to be done in this area to get to what I am talking about).

I don't know that I want a new developer to have to learn XAML AND MSBuild just to understand how our build works (see my following comment on build DSLs).

I would like to make sure here that "learning Xaml" isn't being distorted by your perception of how complex WPF is.  They are totally separate. Xaml is just XML, and I think as far as its object definition qualities go, developers can jump right in, as they can leverage the ubiquitousness (that's a word haha) of XML.
With all of this said, I am 100% with you about Roslyn and its new tooling.  What I personally would like to see done is a new "Data AST (Abstract Syntax Tree) Format" that is a new file format (call it .dast for the sake of this discussion).  When this file is opened in Visual Studio, it displays it to the developer in the format that the developer prefers it (JSON, XML, Xaml, Yaml, etc etc).
That way, the data gets saved (in a particular format, which may or may not be proprietary), and then whenever it is opened, it is presented in a preferred format, and is designed so accordingly.
Not sure how viable that is short-term and what that means for MSBuild, however. :)  The thing you are fighting with me here on is that I (and you, it sounds) know what the Xaml development/designer experience is like, and it's quite nice (especially with ReSharper).  JSON development/designer support is going to be a while before it gets up to Xaml-status (plus it suffers from multiple-artifact syndrome which I still think needs to be resolved elegantly).  I also feel that Xaml is a natural successor to the existing XML file format, especially since we are talking about a C#/VB/.NET where all of these projects have been built by MSBuild for over a decade.
Admittedly, I am not aware of the other technologies you reference, so I guess I have some research to do.  I just cringe whenever I see code that can be defined declaratively, and that's really what we're after here.
I hope this clarifies my position.  Thank you again for your input.

Just thinking about this some more and to echo what @RichiCoder1 said... if you cleanly expose the API as C# (or even .NET) objects, then we Xamlites (I just made that up) can build Xaml around that.  It doesn't really need to be anything special, especially with what Xamarin is cooking up these days.  There's no reason not to support both JSON and Xaml, I guess is what I am trying to say.  Heck, if you make JSON the official supported file type (not saying that you should :sweat_smile:, but if you do), I could see myself making a fork that enables the corresponding Xaml equivalent functionality, for starters.
(FWIW, this is what I intend on doing with ASP.NET 5's  new configuration API, which is designed to support different configuration providers/formats.)
As long as the MSBuild team is aware of the want/need for multiple declarative file format support and provide the necessary design/hooks to easily consume their API in whatever format we prefer, that's what's really important here. :+1:

I like the XAML idea. I do think that the class in this case is an artifact. However, it is an artifact that also represents the internal .NET object. The System.Xaml.XamlReader class has a mature implementation that reads that in for us, with strong type checking. Because of this, the MsBuild system could pre-compile the build definition into BAML (the binary representation of XAML). This could make the build system much faster, since BAML translates to an in-memory object more efficiently than runtime string parsing and schema checking.

@eatdrinksleepcode is on the right track.+1 to C# scripting

@Michael-DST An pluggable, language/format-agnostic API/interface for MSBuild would probably tops really, as this thread shows theres many different formats that people'd like to define builds in. That being said, that'd be no small task, and still probably require one or more built in build configuration parsers.

Yes, and now thinking about it, there really isn't a need for a proprietary file format (.dast) after all (although you could still create one from a branding/optimized/value perspective).  It really comes down to the data (saved/stored format) and the view (presentation format).  Roslyn offers pretty exciting improvements in this regard and can handle everything in between.  Once Visual Studio loads the file, it can run its own conversion process (via Roslyn) between the two formats.
It will be an awesome day in technology when one can open up a .json file, have it render as .xaml via Roslyn conversion, edit/design as .xaml, and then when saved, it saves it as back as .json.  And vice versa. :)
(Although, JSON does not support markup extensions -- ahem :innocent: -- so some additional thought would be required around that and other capability discrepancies.)
As an aside, I would be remiss if I didn't mention my vote on Visual Studio for .ast code views.  I am beginning to feel that the .dast we are talking about here is an extension component of this concept.  You are right in saying that this is no small task, and I hope to inspire some light bulbs out there by mentioning it to get the ball rolling.  I feel this thread really underscores that we are "pawing at an elephant in a dark room" here that and this "elephant" is bound to be a legitimate GitHub project at some point -- either officially by MSFT or by someone with extra time on their hands (which is obviously not me at the moment :smile:).  If someone started it, I for one would totally support it.  This is a well-overdue feature for software development!

@eatdrinksleepcode totally agree, but I guess adding JSON/YAML support is easier?

If it's simply a serialization format such as JSON or YAML, please make the serializer itself being used swappable through configuration, etc. I also like the idea of being able to use C# directly, however I could see that making things a bit more difficult as the abstraction would have to be higher up than just the serializer.

@arthur-peka, another markup langauge would undoubtedly be easier, as the current model is built with a markup language in mind. But just because it is easier does not mean it is the right direction for the future :)
Implementing scripting language support may ultimately deserve its own proposal, but given that even implementing another markup language is considered "distant future", I don't think it is worth tracking scripting language support separately right now. I mostly just want people who are interested in and thinking about implementing something other than XML for MSBuild to have scripting in mind.

@leppie, you can write JSON schema today, see https://github.com/json-schema/json-schema. @madskristensen has written handful of schemas for various implementations: .jshintrc, .jscsrc, tslit.json, package.json (node.js) etc. which works with both VS2013 and VS2015. Also check this out https://github.com/madskristensen/JSON-Intellisense/blob/master/README.md,

No JSON, please.
JSON is a data-interchange format. It was never "designed" to be used as a source format.
JSON is hard to merge. JSON has odd syntactical requirements that insert noise in places that handily confuse merge tools. Remember, project files are basically part of the project's source, and so need to be as friendly to all tools as possible, including merge tools.
ex: The need in JSON to put a trailing comma after every item in an array/object except the last one means that merging two edits that both add items to the end of a list is always a conflict, unnecessarily. Let's not then get started on the problems of users adding single-line arrays/objects and conflicts there-in (the same thing can happen with XML, but such single-line structures aren't nearly as idiomatic/common in XML as they are in JSON).
This is why projects like HJSON exist. If you're arguing for a cleaner and more human-friendly file format, the mere existence of projects like HJSON should rather clearly indicate that JSON itself is a bad choice (in many ways, it's a step backwards from XML). HJSON also avoids the indentation madness of YAML, btw. And HJSON is just a dialect of JSON, so it's conceptually compatible with all the schema tools that people have tried to bolt on to JSON a posteriori ... I'm saying you should look into HJSON. :)
Also, XML is a perfectly fine language if used well. Unfortunately, msbuild's current schema is poorly designed and endemic to Microsoft's culture from the late 90's and early 00's. A rewrite and massive cleanup and redesign of the schema would do wonders without actually needing to support a new data format. Also, that macro language in msbuild... switching to a new data format won't fix that. Point being, if your complaint is that msbuild's specification is complicated and ugly, blame of XML is massively misplaced.

Wow @seanmiddleditch that HJSON is indeed very telling, exactly as you put it.  Great find.  Does this mean we can make  HXaml and all will be right in the world? :)

@Michael-DST : sure. I don't know of any standard (I'm 93% sure there is one if you look hard enough), but there's almost more home-grown "HXML"-like formats than you can shake a stick at. Jade is the best standard I can think of here, though it's HTML-focused and relies on whitespace/indentation for structure.
A human-readable dialect is still very much second fiddle to the actual schema itself, though. The most pleasant and concise syntax in the world is worthless if the structure itself is poor.
Consider Google's gyp, which is a JSON-based meta-project system (akin to CMake). I still think that Gyp has the hardest to read project files of all the tools of its ilk. Consider just the tail end of the sample .gyp file from that link:
         ],
        }]
      ],
    },
  ],
}

And before someone else mentions it: yes, there are JSON-aware merge algorithms, but source data formats like Microsoft's project files need to be compatible with all the merge tools in common use, most of which can barely manage simple text adequately much less formats that require special merge algorithms.

For anyone who is interested, I have created a UserVoice vote on Visual Studio that mentions this great discussion and defines the problems with the current build system that need to be addressed:
http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/9347001-improve-reboot-visual-studio-project-system
Additionally, I have proposed a new idea/vote on UserVoice for an idea that would also address this problem from a developer perspective:
http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/10020525-enable-roslyn-powered-data-asts-and-data-views
In this vote, there is a blog post that explains the idea in more detail.  Thank you for any feedback and/or support. :)

This is a little late here, but I just got done making a simple app that demonstrates what I discussed above with Xaml-based application development.  Please see this file:
https://github.com/DragonSpark/VoteReporter/blob/master/DevelopersWin.VoteReporter.Application/Program.xaml
And (probably more importantly?) this file: https://github.com/DragonSpark/VoteReporter/blob/master/DevelopersWin.VoteReporter.Application/Program.xaml.cs
Here is a good example of a Xaml-driven application (or at least my definition of it) -- or more succinctly a Xaml-driven Console Application (you can see in the code-behind above how the Main method is defined).  In this case, all of the "steps" of the application startup are encapsulated in System.Windows.Input.ICommand's and they are called in succession to execute very discrete and encapsulated commands. These commands are then defined in the Program.xaml file as Xaml elements that can be used to define all of the inputs and (what others might consider) configuration for the application.
The power again is the markup extensions.  There are some really cool ones here that are being used, such as creating a DirectoryInfo object that is used by subsequent components via IoC: https://github.com/DragonSpark/VoteReporter/blob/master/DevelopersWin.VoteReporter.Application/Program.xaml#L22
Additionally, this line tells the application to pull all registered IInstaller's found within the current AppDomain and add them to the collection found within the InitializeDatabaseCommand:
https://github.com/DragonSpark/VoteReporter/blob/master/DevelopersWin.VoteReporter.Application/Program.xaml#L44
Very powerful stuff (I say, as I wrote it, LOL).  In any case, this is how I see/envision MSBuild vNext being implemented, and the new build projects looking very much like this.  It doesn't take much of a jump to see that ICommands could be build Tasks (or probably both? that is, Tasks implement ICommand?) and they can (should) be defined in very much the same way.  Anyways, I just had to share.  Thanks again for any consideration/discussion.

Hi,
Being a user of msbuild myself, I think it is good that you are deciding to possibly use json/yaml.
I went online and converted a msbuild c++ project which looked like this:
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <ItemGroup Label="ProjectConfigurations">
    <ProjectConfiguration Include="Debug|x64">
      <Configuration>Debug</Configuration>
      <Platform>x64</Platform>
    </ProjectConfiguration>
    <ProjectConfiguration Include="Release|x64">
      <Configuration>Release</Configuration>
      <Platform>x64</Platform>
    </ProjectConfiguration>
  </ItemGroup>
  <PropertyGroup Label="Globals">
    <ProjectGuid>{74CF4537-8047-617D-4D23-0353B4FC702F}</ProjectGuid>
    <Keyword>Win32Proj</Keyword>
    <RootNamespace>pem</RootNamespace>
    <IgnoreWarnCompileDuplicatedFilename>true</IgnoreWarnCompileDuplicatedFilename>
    <PreferredToolArchitecture>x64</PreferredToolArchitecture>
  </PropertyGroup>
  <Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props"/>
  <PropertyGroup Label="Configuration">
    <ConfigurationType>DynamicLibrary</ConfigurationType>
  </PropertyGroup>
  <PropertyGroup Label="Locals">
    <PlatformToolset>v140</PlatformToolset>
  </PropertyGroup>
  <Import Project="$(VCTargetsPath)\Microsoft.Cpp.props"/>
  <Import Project="$(VCTargetsPath)\BuildCustomizations\masm.props"/>
  <ImportGroup Label="ExtensionSettings"/>
  <ImportGroup Label="PropertySheets">
    <Import Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props"/>
  </ImportGroup>
  <PropertyGroup Label="UserMacros"/>
  <PropertyGroup>
    <ExecutablePath>$(ExecutablePath);$(MSBuildProjectDirectory)\..\bin\;$(MSBuildProjectDirectory)\..\bin\</ExecutablePath>
    <IgnoreImportLibrary>true</IgnoreImportLibrary>
    <IntDir>$(Configuration)\obj\$(ProjectName)\</IntDir>
    <LinkIncremental Condition="'$(Configuration)|$(Platform)'=='Release|x64'">false</LinkIncremental>
    <LinkIncremental Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">true</LinkIncremental>
    <OutDir>$(SolutionDir)$(Configuration)\</OutDir>
    <TargetExt Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">.node</TargetExt>
    <TargetExt Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">.node</TargetExt>
    <TargetExt Condition="'$(Configuration)|$(Platform)'=='Release|x64'">.node</TargetExt>
    <TargetExt Condition="'$(Configuration)|$(Platform)'=='Release|x64'">.node</TargetExt>
    <TargetName>$(ProjectName)</TargetName>
    <TargetPath>$(OutDir)\$(ProjectName).node</TargetPath>
  </PropertyGroup>
  <ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
    <ClCompile>
      <AdditionalIncludeDirectories>C:\Users\Kishan Sambhi\.node-gyp\4.2.2\include\node;C:\Users\Kishan Sambhi\.node-gyp\4.2.2\src;C:\Users\Kishan Sambhi\.node-gyp\4.2.2\deps\uv\include;C:\Users\Kishan Sambhi\.node-gyp\4.2.2\deps\v8\include;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
      <BasicRuntimeChecks>EnableFastChecks</BasicRuntimeChecks>
      <BufferSecurityCheck>true</BufferSecurityCheck>
      <CompileAsWinRT>false</CompileAsWinRT>
      <DebugInformationFormat>ProgramDatabase</DebugInformationFormat>
      <DisableSpecificWarnings>4351;4355;4800;4251;%(DisableSpecificWarnings)</DisableSpecificWarnings>
      <ExceptionHandling>false</ExceptionHandling>
      <MinimalRebuild>false</MinimalRebuild>
      <OmitFramePointers>false</OmitFramePointers>
      <Optimization>Disabled</Optimization>
      <PrecompiledHeader>NotUsing</PrecompiledHeader>
      <PreprocessorDefinitions>NODE_GYP_MODULE_NAME=pem;WIN32;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE;_HAS_EXCEPTIONS=0;BUILDING_V8_SHARED=1;BUILDING_UV_SHARED=1;BUILDING_NODE_EXTENSION;DEBUG;_DEBUG;%(PreprocessorDefinitions)</PreprocessorDefinitions>
      <RuntimeLibrary>MultiThreadedDebug</RuntimeLibrary>
      <StringPooling>true</StringPooling>
      <SuppressStartupBanner>true</SuppressStartupBanner>
      <TreatWarningAsError>false</TreatWarningAsError>
      <WarningLevel>Level3</WarningLevel>
    </ClCompile>
    <Link>
      <AdditionalDependencies>kernel32.lib;user32.lib;gdi32.lib;winspool.lib;comdlg32.lib;advapi32.lib;shell32.lib;ole32.lib;oleaut32.lib;uuid.lib;odbc32.lib;DelayImp.lib;"C:\Users\Kishan Sambhi\.node-gyp\4.2.2\$(Configuration)\node.lib"</AdditionalDependencies>
      <AdditionalOptions>/ignore:4199 %(AdditionalOptions)</AdditionalOptions>
      <AllowIsolation>true</AllowIsolation>
      <DataExecutionPrevention>true</DataExecutionPrevention>
      <DelayLoadDLLs>iojs.exe;node.exe;%(DelayLoadDLLs)</DelayLoadDLLs>
      <GenerateDebugInformation>true</GenerateDebugInformation>
      <GenerateMapFile>true</GenerateMapFile>
      <MapExports>true</MapExports>
      <OutputFile>$(OutDir)$(ProjectName).node</OutputFile>
      <RandomizedBaseAddress>true</RandomizedBaseAddress>
      <SuppressStartupBanner>true</SuppressStartupBanner>
      <TargetExt>.node</TargetExt>
      <TargetMachine>MachineX64</TargetMachine>
    </Link>
    <ResourceCompile>
      <AdditionalIncludeDirectories>C:\Users\Kishan Sambhi\.node-gyp\4.2.2\include\node;C:\Users\Kishan Sambhi\.node-gyp\4.2.2\src;C:\Users\Kishan Sambhi\.node-gyp\4.2.2\deps\uv\include;C:\Users\Kishan Sambhi\.node-gyp\4.2.2\deps\v8\include;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
      <PreprocessorDefinitions>NODE_GYP_MODULE_NAME=pem;WIN32;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE;_HAS_EXCEPTIONS=0;BUILDING_V8_SHARED=1;BUILDING_UV_SHARED=1;BUILDING_NODE_EXTENSION;DEBUG;_DEBUG;%(PreprocessorDefinitions);%(PreprocessorDefinitions)</PreprocessorDefinitions>
    </ResourceCompile>
  </ItemDefinitionGroup>
  <ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
    <ClCompile>
      <AdditionalIncludeDirectories>C:\Users\Kishan Sambhi\.node-gyp\4.2.2\include\node;C:\Users\Kishan Sambhi\.node-gyp\4.2.2\src;C:\Users\Kishan Sambhi\.node-gyp\4.2.2\deps\uv\include;C:\Users\Kishan Sambhi\.node-gyp\4.2.2\deps\v8\include;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
      <AdditionalOptions>/MP %(AdditionalOptions)</AdditionalOptions>
      <BufferSecurityCheck>true</BufferSecurityCheck>
      <CompileAsWinRT>false</CompileAsWinRT>
      <DebugInformationFormat>ProgramDatabase</DebugInformationFormat>
      <DisableSpecificWarnings>4351;4355;4800;4251;%(DisableSpecificWarnings)</DisableSpecificWarnings>
      <ExceptionHandling>false</ExceptionHandling>
      <FavorSizeOrSpeed>Speed</FavorSizeOrSpeed>
      <FunctionLevelLinking>true</FunctionLevelLinking>
      <InlineFunctionExpansion>AnySuitable</InlineFunctionExpansion>
      <IntrinsicFunctions>true</IntrinsicFunctions>
      <OmitFramePointers>true</OmitFramePointers>
      <Optimization>Full</Optimization>
      <PrecompiledHeader>NotUsing</PrecompiledHeader>
      <PreprocessorDefinitions>NODE_GYP_MODULE_NAME=pem;WIN32;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE;_HAS_EXCEPTIONS=0;BUILDING_V8_SHARED=1;BUILDING_UV_SHARED=1;BUILDING_NODE_EXTENSION;%(PreprocessorDefinitions)</PreprocessorDefinitions>
      <RuntimeLibrary>MultiThreaded</RuntimeLibrary>
      <RuntimeTypeInfo>false</RuntimeTypeInfo>
      <StringPooling>true</StringPooling>
      <SuppressStartupBanner>true</SuppressStartupBanner>
      <TreatWarningAsError>false</TreatWarningAsError>
      <WarningLevel>Level3</WarningLevel>
      <WholeProgramOptimization>true</WholeProgramOptimization>
    </ClCompile>
    <Lib>
      <AdditionalOptions>/LTCG %(AdditionalOptions)</AdditionalOptions>
    </Lib>
    <Link>
      <AdditionalDependencies>kernel32.lib;user32.lib;gdi32.lib;winspool.lib;comdlg32.lib;advapi32.lib;shell32.lib;ole32.lib;oleaut32.lib;uuid.lib;odbc32.lib;DelayImp.lib;"C:\Users\Kishan Sambhi\.node-gyp\4.2.2\$(Configuration)\node.lib"</AdditionalDependencies>
      <AdditionalOptions>/ignore:4199 %(AdditionalOptions)</AdditionalOptions>
      <AllowIsolation>true</AllowIsolation>
      <DataExecutionPrevention>true</DataExecutionPrevention>
      <DelayLoadDLLs>iojs.exe;node.exe;%(DelayLoadDLLs)</DelayLoadDLLs>
      <EnableCOMDATFolding>true</EnableCOMDATFolding>
      <GenerateDebugInformation>true</GenerateDebugInformation>
      <GenerateMapFile>true</GenerateMapFile>
      <LinkTimeCodeGeneration>UseLinkTimeCodeGeneration</LinkTimeCodeGeneration>
      <MapExports>true</MapExports>
      <OptimizeReferences>true</OptimizeReferences>
      <OutputFile>$(OutDir)$(ProjectName).node</OutputFile>
      <RandomizedBaseAddress>true</RandomizedBaseAddress>
      <SuppressStartupBanner>true</SuppressStartupBanner>
      <TargetExt>.node</TargetExt>
      <TargetMachine>MachineX64</TargetMachine>
    </Link>
    <ResourceCompile>
      <AdditionalIncludeDirectories>C:\Users\Kishan Sambhi\.node-gyp\4.2.2\include\node;C:\Users\Kishan Sambhi\.node-gyp\4.2.2\src;C:\Users\Kishan Sambhi\.node-gyp\4.2.2\deps\uv\include;C:\Users\Kishan Sambhi\.node-gyp\4.2.2\deps\v8\include;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
      <PreprocessorDefinitions>NODE_GYP_MODULE_NAME=pem;WIN32;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE;_HAS_EXCEPTIONS=0;BUILDING_V8_SHARED=1;BUILDING_UV_SHARED=1;BUILDING_NODE_EXTENSION;%(PreprocessorDefinitions);%(PreprocessorDefinitions)</PreprocessorDefinitions>
    </ResourceCompile>
  </ItemDefinitionGroup>
  <ItemGroup>
    <None Include="..\binding.gyp"/>
  </ItemGroup>
  <ItemGroup>
    <ClCompile Include="..\src\pem.cc"/>
    <ClCompile Include="C:\Users\Kishan Sambhi\AppData\Roaming\npm\node_modules\node-gyp\src\win_delay_load_hook.c"/>
  </ItemGroup>
  <Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets"/>
  <Import Project="$(VCTargetsPath)\BuildCustomizations\masm.targets"/>
  <ImportGroup Label="ExtensionTargets"/>
</Project>

to json and yaml
JSON:
{
  "Project": {
    "-xmlns": "http://schemas.microsoft.com/developer/msbuild/2003",
    "-DefaultTargets": "Build",
    "-ToolsVersion": "14.0",
    "ItemGroup": [
      {
        "-Label": "ProjectConfigurations",
        "ProjectConfiguration": [
          {
            "-Include": "Debug|x64",
            "Configuration": "Debug",
            "Platform": "x64"
          },
          {
            "-Include": "Release|x64",
            "Configuration": "Release",
            "Platform": "x64"
          }
        ]
      },
      {
        "None": { "-Include": "..\\binding.gyp" }
      },
      {
        "ClCompile": [
          { "-Include": "..\\src\\pem.cc" },
          { "-Include": "C:\\Users\\Kishan Sambhi\\AppData\\Roaming\\npm\\node_modules\\node-gyp\\src\\win_delay_load_hook.c" }
        ]
      }
    ],
    "PropertyGroup": [
      {
        "-Label": "Globals",
        "ProjectGuid": "{74CF4537-8047-617D-4D23-0353B4FC702F}",
        "Keyword": "Win32Proj",
        "RootNamespace": "pem",
        "IgnoreWarnCompileDuplicatedFilename": "true",
        "PreferredToolArchitecture": "x64"
      },
      {
        "-Label": "Configuration",
        "ConfigurationType": "DynamicLibrary"
      },
      {
        "-Label": "Locals",
        "PlatformToolset": "v140"
      },
      { "-Label": "UserMacros" },
      {
        "ExecutablePath": "$(ExecutablePath);$(MSBuildProjectDirectory)\\..\\bin\\;$(MSBuildProjectDirectory)\\..\\bin\\",
        "IgnoreImportLibrary": "true",
        "IntDir": "$(Configuration)\\obj\\$(ProjectName)\\",
        "LinkIncremental": [
          {
            "-Condition": "'$(Configuration)|$(Platform)'=='Release|x64'",
            "#text": "false"
          },
          {
            "-Condition": "'$(Configuration)|$(Platform)'=='Debug|x64'",
            "#text": "true"
          }
        ],
        "OutDir": "$(SolutionDir)$(Configuration)\\",
        "TargetExt": [
          {
            "-Condition": "'$(Configuration)|$(Platform)'=='Debug|x64'",
            "#text": ".node"
          },
          {
            "-Condition": "'$(Configuration)|$(Platform)'=='Debug|x64'",
            "#text": ".node"
          },
          {
            "-Condition": "'$(Configuration)|$(Platform)'=='Release|x64'",
            "#text": ".node"
          },
          {
            "-Condition": "'$(Configuration)|$(Platform)'=='Release|x64'",
            "#text": ".node"
          }
        ],
        "TargetName": "$(ProjectName)",
        "TargetPath": "$(OutDir)\\$(ProjectName).node"
      }
    ],
    "Import": [
      { "-Project": "$(VCTargetsPath)\\Microsoft.Cpp.Default.props" },
      { "-Project": "$(VCTargetsPath)\\Microsoft.Cpp.props" },
      { "-Project": "$(VCTargetsPath)\\BuildCustomizations\\masm.props" },
      { "-Project": "$(VCTargetsPath)\\Microsoft.Cpp.targets" },
      { "-Project": "$(VCTargetsPath)\\BuildCustomizations\\masm.targets" }
    ],
    "ImportGroup": [
      { "-Label": "ExtensionSettings" },
      {
        "-Label": "PropertySheets",
        "Import": {
          "-Condition": "exists('$(UserRootDir)\\Microsoft.Cpp.$(Platform).user.props')",
          "-Label": "LocalAppDataPlatform",
          "-Project": "$(UserRootDir)\\Microsoft.Cpp.$(Platform).user.props"
        }
      },
      { "-Label": "ExtensionTargets" }
    ],
    "ItemDefinitionGroup": [
      {
        "-Condition": "'$(Configuration)|$(Platform)'=='Debug|x64'",
        "ClCompile": {
          "AdditionalIncludeDirectories": "C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\include\\node;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\src;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\deps\\uv\\include;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\deps\\v8\\include;%(AdditionalIncludeDirectories)",
          "BasicRuntimeChecks": "EnableFastChecks",
          "BufferSecurityCheck": "true",
          "CompileAsWinRT": "false",
          "DebugInformationFormat": "ProgramDatabase",
          "DisableSpecificWarnings": "4351;4355;4800;4251;%(DisableSpecificWarnings)",
          "ExceptionHandling": "false",
          "MinimalRebuild": "false",
          "OmitFramePointers": "false",
          "Optimization": "Disabled",
          "PrecompiledHeader": "NotUsing",
          "PreprocessorDefinitions": "NODE_GYP_MODULE_NAME=pem;WIN32;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE;_HAS_EXCEPTIONS=0;BUILDING_V8_SHARED=1;BUILDING_UV_SHARED=1;BUILDING_NODE_EXTENSION;DEBUG;_DEBUG;%(PreprocessorDefinitions)",
          "RuntimeLibrary": "MultiThreadedDebug",
          "StringPooling": "true",
          "SuppressStartupBanner": "true",
          "TreatWarningAsError": "false",
          "WarningLevel": "Level3"
        },
        "Link": {
          "AdditionalDependencies": "kernel32.lib;user32.lib;gdi32.lib;winspool.lib;comdlg32.lib;advapi32.lib;shell32.lib;ole32.lib;oleaut32.lib;uuid.lib;odbc32.lib;DelayImp.lib;\"C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\$(Configuration)\\node.lib\"",
          "AdditionalOptions": "/ignore:4199 %(AdditionalOptions)",
          "AllowIsolation": "true",
          "DataExecutionPrevention": "true",
          "DelayLoadDLLs": "iojs.exe;node.exe;%(DelayLoadDLLs)",
          "GenerateDebugInformation": "true",
          "GenerateMapFile": "true",
          "MapExports": "true",
          "OutputFile": "$(OutDir)$(ProjectName).node",
          "RandomizedBaseAddress": "true",
          "SuppressStartupBanner": "true",
          "TargetExt": ".node",
          "TargetMachine": "MachineX64"
        },
        "ResourceCompile": {
          "AdditionalIncludeDirectories": "C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\include\\node;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\src;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\deps\\uv\\include;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\deps\\v8\\include;%(AdditionalIncludeDirectories)",
          "PreprocessorDefinitions": "NODE_GYP_MODULE_NAME=pem;WIN32;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE;_HAS_EXCEPTIONS=0;BUILDING_V8_SHARED=1;BUILDING_UV_SHARED=1;BUILDING_NODE_EXTENSION;DEBUG;_DEBUG;%(PreprocessorDefinitions);%(PreprocessorDefinitions)"
        }
      },
      {
        "-Condition": "'$(Configuration)|$(Platform)'=='Release|x64'",
        "ClCompile": {
          "AdditionalIncludeDirectories": "C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\include\\node;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\src;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\deps\\uv\\include;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\deps\\v8\\include;%(AdditionalIncludeDirectories)",
          "AdditionalOptions": "/MP %(AdditionalOptions)",
          "BufferSecurityCheck": "true",
          "CompileAsWinRT": "false",
          "DebugInformationFormat": "ProgramDatabase",
          "DisableSpecificWarnings": "4351;4355;4800;4251;%(DisableSpecificWarnings)",
          "ExceptionHandling": "false",
          "FavorSizeOrSpeed": "Speed",
          "FunctionLevelLinking": "true",
          "InlineFunctionExpansion": "AnySuitable",
          "IntrinsicFunctions": "true",
          "OmitFramePointers": "true",
          "Optimization": "Full",
          "PrecompiledHeader": "NotUsing",
          "PreprocessorDefinitions": "NODE_GYP_MODULE_NAME=pem;WIN32;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE;_HAS_EXCEPTIONS=0;BUILDING_V8_SHARED=1;BUILDING_UV_SHARED=1;BUILDING_NODE_EXTENSION;%(PreprocessorDefinitions)",
          "RuntimeLibrary": "MultiThreaded",
          "RuntimeTypeInfo": "false",
          "StringPooling": "true",
          "SuppressStartupBanner": "true",
          "TreatWarningAsError": "false",
          "WarningLevel": "Level3",
          "WholeProgramOptimization": "true"
        },
        "Lib": { "AdditionalOptions": "/LTCG %(AdditionalOptions)" },
        "Link": {
          "AdditionalDependencies": "kernel32.lib;user32.lib;gdi32.lib;winspool.lib;comdlg32.lib;advapi32.lib;shell32.lib;ole32.lib;oleaut32.lib;uuid.lib;odbc32.lib;DelayImp.lib;\"C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\$(Configuration)\\node.lib\"",
          "AdditionalOptions": "/ignore:4199 %(AdditionalOptions)",
          "AllowIsolation": "true",
          "DataExecutionPrevention": "true",
          "DelayLoadDLLs": "iojs.exe;node.exe;%(DelayLoadDLLs)",
          "EnableCOMDATFolding": "true",
          "GenerateDebugInformation": "true",
          "GenerateMapFile": "true",
          "LinkTimeCodeGeneration": "UseLinkTimeCodeGeneration",
          "MapExports": "true",
          "OptimizeReferences": "true",
          "OutputFile": "$(OutDir)$(ProjectName).node",
          "RandomizedBaseAddress": "true",
          "SuppressStartupBanner": "true",
          "TargetExt": ".node",
          "TargetMachine": "MachineX64"
        },
        "ResourceCompile": {
          "AdditionalIncludeDirectories": "C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\include\\node;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\src;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\deps\\uv\\include;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\deps\\v8\\include;%(AdditionalIncludeDirectories)",
          "PreprocessorDefinitions": "NODE_GYP_MODULE_NAME=pem;WIN32;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE;_HAS_EXCEPTIONS=0;BUILDING_V8_SHARED=1;BUILDING_UV_SHARED=1;BUILDING_NODE_EXTENSION;%(PreprocessorDefinitions);%(PreprocessorDefinitions)"
        }
      }
    ]
  }
}

YAML
Project:
 ItemGroup:
  -
   ProjectConfiguration:
    -
   Configuration: Debug
     Platform: x64
     _Include: "Debug|x64"
    -
   Configuration: Release
     Platform: x64
     _Include: "Release|x64"
   _Label: ProjectConfigurations
  -
   None:
    _Include: "..\\binding.gyp"
  -
   ClCompile:
    -
   _Include: "..\\src\\pem.cc"
    -
   _Include: "C:\\Users\\Kishan Sambhi\\AppData\\Roaming\\npm\\node_modules\\node-gyp\\src\\win_delay_load_hook.c"
 PropertyGroup:
  -
   ProjectGuid: "{74CF4537-8047-617D-4D23-0353B4FC702F}"
   Keyword: Win32Proj
   RootNamespace: pem
   IgnoreWarnCompileDuplicatedFilename: true
   PreferredToolArchitecture: x64
   _Label: Globals
  -
   ConfigurationType: DynamicLibrary
   _Label: Configuration
  -
   PlatformToolset: v140
   _Label: Locals
  -
   _Label: UserMacros
  -
   ExecutablePath: "$(ExecutablePath);$(MSBuildProjectDirectory)\\..\\bin\\;$(MSBuildProjectDirectory)\\..\\bin\\"
   IgnoreImportLibrary: true
   IntDir: "$(Configuration)\\obj\\$(ProjectName)\\"
   LinkIncremental:
    -
   _Condition: "'$(Configuration)|$(Platform)'=='Release|x64'"
     __text: false
     toString:
    -
   _Condition: "'$(Configuration)|$(Platform)'=='Debug|x64'"
     __text: true
     toString:
   OutDir: "$(SolutionDir)$(Configuration)\\"
   TargetExt:
    -
   _Condition: "'$(Configuration)|$(Platform)'=='Debug|x64'"
     __text: ".node"
     toString:
    -
   _Condition: "'$(Configuration)|$(Platform)'=='Debug|x64'"
     __text: ".node"
     toString:
    -
   _Condition: "'$(Configuration)|$(Platform)'=='Release|x64'"
     __text: ".node"
     toString:
    -
   _Condition: "'$(Configuration)|$(Platform)'=='Release|x64'"
     __text: ".node"
     toString:
   TargetName: "$(ProjectName)"
   TargetPath: "$(OutDir)\\$(ProjectName).node"
 Import:
  -
   _Project: "$(VCTargetsPath)\\Microsoft.Cpp.Default.props"
  -
   _Project: "$(VCTargetsPath)\\Microsoft.Cpp.props"
  -
   _Project: "$(VCTargetsPath)\\BuildCustomizations\\masm.props"
  -
   _Project: "$(VCTargetsPath)\\Microsoft.Cpp.targets"
  -
   _Project: "$(VCTargetsPath)\\BuildCustomizations\\masm.targets"
 ImportGroup:
  -
   _Label: ExtensionSettings
  -
   Import:
    _Condition: "exists('$(UserRootDir)\\Microsoft.Cpp.$(Platform).user.props')"
    _Label: LocalAppDataPlatform
    _Project: "$(UserRootDir)\\Microsoft.Cpp.$(Platform).user.props"
   _Label: PropertySheets
  -
   _Label: ExtensionTargets
 ItemDefinitionGroup:
  -
   ClCompile:
    AdditionalIncludeDirectories: "C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\include\\node;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\src;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\deps\\uv\\include;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\deps\\v8\\include;%(AdditionalIncludeDirectories)"
    BasicRuntimeChecks: EnableFastChecks
    BufferSecurityCheck: true
    CompileAsWinRT: false
    DebugInformationFormat: ProgramDatabase
    DisableSpecificWarnings: "4351;4355;4800;4251;%(DisableSpecificWarnings)"
    ExceptionHandling: false
    MinimalRebuild: false
    OmitFramePointers: false
    Optimization: Disabled
    PrecompiledHeader: NotUsing
    PreprocessorDefinitions: "NODE_GYP_MODULE_NAME=pem;WIN32;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE;_HAS_EXCEPTIONS=0;BUILDING_V8_SHARED=1;BUILDING_UV_SHARED=1;BUILDING_NODE_EXTENSION;DEBUG;_DEBUG;%(PreprocessorDefinitions)"
    RuntimeLibrary: MultiThreadedDebug
    StringPooling: true
    SuppressStartupBanner: true
    TreatWarningAsError: false
    WarningLevel: Level3
   Link:
    AdditionalDependencies: "kernel32.lib;user32.lib;gdi32.lib;winspool.lib;comdlg32.lib;advapi32.lib;shell32.lib;ole32.lib;oleaut32.lib;uuid.lib;odbc32.lib;DelayImp.lib;\"C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\$(Configuration)\\node.lib\""
    AdditionalOptions: "/ignore:4199 %(AdditionalOptions)"
    AllowIsolation: true
    DataExecutionPrevention: true
    DelayLoadDLLs: "iojs.exe;node.exe;%(DelayLoadDLLs)"
    GenerateDebugInformation: true
    GenerateMapFile: true
    MapExports: true
    OutputFile: "$(OutDir)$(ProjectName).node"
    RandomizedBaseAddress: true
    SuppressStartupBanner: true
    TargetExt: ".node"
    TargetMachine: MachineX64
   ResourceCompile:
    AdditionalIncludeDirectories: "C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\include\\node;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\src;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\deps\\uv\\include;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\deps\\v8\\include;%(AdditionalIncludeDirectories)"
    PreprocessorDefinitions: "NODE_GYP_MODULE_NAME=pem;WIN32;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE;_HAS_EXCEPTIONS=0;BUILDING_V8_SHARED=1;BUILDING_UV_SHARED=1;BUILDING_NODE_EXTENSION;DEBUG;_DEBUG;%(PreprocessorDefinitions);%(PreprocessorDefinitions)"
   _Condition: "'$(Configuration)|$(Platform)'=='Debug|x64'"
  -
   ClCompile:
    AdditionalIncludeDirectories: "C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\include\\node;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\src;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\deps\\uv\\include;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\deps\\v8\\include;%(AdditionalIncludeDirectories)"
    AdditionalOptions: "/MP %(AdditionalOptions)"
    BufferSecurityCheck: true
    CompileAsWinRT: false
    DebugInformationFormat: ProgramDatabase
    DisableSpecificWarnings: "4351;4355;4800;4251;%(DisableSpecificWarnings)"
    ExceptionHandling: false
    FavorSizeOrSpeed: Speed
    FunctionLevelLinking: true
    InlineFunctionExpansion: AnySuitable
    IntrinsicFunctions: true
    OmitFramePointers: true
    Optimization: Full
    PrecompiledHeader: NotUsing
    PreprocessorDefinitions: "NODE_GYP_MODULE_NAME=pem;WIN32;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE;_HAS_EXCEPTIONS=0;BUILDING_V8_SHARED=1;BUILDING_UV_SHARED=1;BUILDING_NODE_EXTENSION;%(PreprocessorDefinitions)"
    RuntimeLibrary: MultiThreaded
    RuntimeTypeInfo: false
    StringPooling: true
    SuppressStartupBanner: true
    TreatWarningAsError: false
    WarningLevel: Level3
    WholeProgramOptimization: true
   Lib:
    AdditionalOptions: "/LTCG %(AdditionalOptions)"
   Link:
    AdditionalDependencies: "kernel32.lib;user32.lib;gdi32.lib;winspool.lib;comdlg32.lib;advapi32.lib;shell32.lib;ole32.lib;oleaut32.lib;uuid.lib;odbc32.lib;DelayImp.lib;\"C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\$(Configuration)\\node.lib\""
    AdditionalOptions: "/ignore:4199 %(AdditionalOptions)"
    AllowIsolation: true
    DataExecutionPrevention: true
    DelayLoadDLLs: "iojs.exe;node.exe;%(DelayLoadDLLs)"
    EnableCOMDATFolding: true
    GenerateDebugInformation: true
    GenerateMapFile: true
    LinkTimeCodeGeneration: UseLinkTimeCodeGeneration
    MapExports: true
    OptimizeReferences: true
    OutputFile: "$(OutDir)$(ProjectName).node"
    RandomizedBaseAddress: true
    SuppressStartupBanner: true
    TargetExt: ".node"
    TargetMachine: MachineX64
   ResourceCompile:
    AdditionalIncludeDirectories: "C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\include\\node;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\src;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\deps\\uv\\include;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\deps\\v8\\include;%(AdditionalIncludeDirectories)"
    PreprocessorDefinitions: "NODE_GYP_MODULE_NAME=pem;WIN32;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE;_HAS_EXCEPTIONS=0;BUILDING_V8_SHARED=1;BUILDING_UV_SHARED=1;BUILDING_NODE_EXTENSION;%(PreprocessorDefinitions);%(PreprocessorDefinitions)"
   _Condition: "'$(Configuration)|$(Platform)'=='Release|x64'"
 _xmlns: "http://schemas.microsoft.com/developer/msbuild/2003"
 _DefaultTargets: Build
 _ToolsVersion: "14.0"

I think the json is a lot more simple.
So, heads up to json! :+1:
What do think?
You can use this to decide.
Happy coding!

Yaml is definitely more concise, that would be my preference from a human-readable perspective.  However, a bigger issue here really comes down to tooling (designer-friendly) and additional value-added features, such as markup extensions.
Additionally, the core problem here is that "Project" (the root element) does not translate to an actual CLR object.  This is a data (xml) document that is read in and parsed to create a CLR object, which is a terribly inefficient way of using XML, as it not only requires more code, but makes it more difficult to be designer-friendly.  So this above all would have to be addressed, first.
In any case, it would be great to see other serialization platforms embrace markup extensions, that would make this conversation easier. :)
Also, while I am dancing around the subject of Xaml, I would like to point out another project that is making its own Xaml engine with all sorts of cool extensions around its binding expressions to make it more developer-friendly.  You can see that here: https://grokys.github.io/perspex/perspex-alpha3/
This is a UI-specific implementation of a Xaml engine, OmniXaml, a Xaml-based serializer which can be found here: https://github.com/SuperJMN/OmniXAML/

Good argument @Michael-DST. I think those issues that you metioned should have been resolved by the time this issue is closed, but thanks for mentioning them. I totally agree with your opinion, but it is harder to see what is grouped together in yaml, whereas in json all you have to do is look for the closing bracket (}). The Xaml projects you mentioned look like it is possible they could be used.
One question: has anyone opened a pull request on this yet, or is it too distant?

Haha... well I say "human-readable" but as we have CLEARLY seen from this thread (and others), it depends on which human is doing the reading. ;)
As for pull requests, not that I know of... just voting and talking.  MSBuild team has been  worryingly quiet around this discussion.

Ok :+1:

Thanks, @Gum-Joe, for going through the exercise of converting the msbuild XML to the proposed alternate formats.
However, I really don't find the JSON or YAML to be any more readable than XML. Maybe it's because I've been using XML since the mid-90's. There is tons of tooling already for XML.
Just my opinion.

@JohnTasler, gyp (a build system) configurations (the .gyp files which can also yield dependency configs) are in JSON and they are pretty self descriptive too.
MSBuild can also take inspiration from the way we call refer script in node.js package.json file, and have an equivalent to Grunt file in C# script to run MSBuild tasks on build events. This will separate nicely and this workflow is working in VS2015 by WebDev team at Microsoft. It goes like this:

Open VS2015 and hit Ctrl+Shift+N and create any project (say C# console app).

Add a file called package.json at the root of the project.

Add a file called Gruntfile.js (or if you prefer gulf..) at the root of the project.

In package.json, add
{
  "name": "pretty-awesome",
  "version": "0.0.1-alpha-001-prerelease",
  "dependencies": {
    "selenium-webdriver": "^2.0.3",
    "grunt-something": "^x.x"
  }
}

Then in Gruntfile you can write JS code and consume selenium-webdriver and grunt-something packages with the access to filesystem I/O, Buffers, System, Network, DB and the whole world! But at this point, if you want to run that JS code everytime you open the project, before/after building it or even at Cleaning the solution, you can do that by right clicking your grunt task in Task Runner Explorer window and it will add a hook comment in your Gruntfile.js. That comment (e.g. /// <binding ProjectOpened='compile-coffeescripts-task' />) in JS code is parsed by VS task runner feature which act like a broker between MSBuild and Node.js (listens to MSBuild's build events and trigger node.js tasks).

Now the way i abstracted out Task Runner of VS2015 = MSBuild-Node.js broker is not true. It is actually MSbuild and Windows shell contract. Meaning, if you want to run things beyond node.js/grunt/gulp/bower jobs, you can still do that. So with only package.json at your project root:
{
  "name": "pretty-awesome",
  "version": "0.0.1-alpha-001-prerelease",
  "scripts": {
    "job1": "..\\..\\my-old-projects\\c-sharp\\bin\\Release\\FileSystemTasks.exe",
    "job2": "C:\\temp\\writteninC-Cpp.exe",
    "job3": "scriptcs path\\to\\some.csx",
    "job4": "nodejs foo\\run-cs-linter-and-code-styler-for-all-cs-files-in-project.js",
    "job5": "ruby abc.rb",
    "job6": "perl download-somestuff-in-this-dir.pl",
    "job7": "python read-whole-thesaurus-from-mongo-db.py",
  },
  "-vs-binding": {
    "AfterBuild": [ "job1", "job2" ],
    "Clean": [ "job3" ]
  }
}

(all these jobs can still have MSbuild bindings information in .json file which Task Runner will stamp that -vs-binding code for you if you right click these jobs in TRExplorer and select desired binding).

This means we virtually have a custom build system which can be written in [m]any language[s] and Task Runner will take care of interfacing with MSBuild. No scary MSBuild Tasks and long spaghetti XMLs. :)
This will be cool if MSBuild embrace this concept and come up with more polished conventions for more focused msbuild.json, so we can do everything in JSON explicitly which we are doing in XML.

This will be cool if MSBuild embrace this concept and come up with more polished conventions for more focused msbuild.json, so we can do everything in JSON explicitly which we are doing in XML.

This is all really well and good @jasonwilliams200OK, and I am in agreement with your (general) goal, except that veteran .NET/MSFT developers are saying that the JSON format does not suit them and adds confusion/inconsistency into their current project/solution structures.
I think there's still some confusion regarding JSON vs. "Spaghetti MSBuild XML" (which I am in full agreement that it is).  It is spaghetti in that it does not represent a full-fidelity POCO object when serialized, and instead uses XDom-to-POCO mapping, which is a terrible, nasty way to define objects and utilize data within a solution.
I am afraid that the same is the case for your package.json document sample above.  Case in point: the -vs-binding property.  Does this translate properly to a POCO .NET property?  If so, I would like to see how and where.  At the very least, there is some (attribute/metadata?) mapping going on as the "-" character is an illegal symbol for a .NET property.  This mapping is ultimately just as bad as XDom-to-POCO, because at the end of the day you are dealing with representative, loosely-typed data (higher total cost of ownership) versus serialized, strongly-typed data (lower TCO).
Don't get me wrong, I see the appeal of JSON, but from a veteran MSFT developer point of view it still has a way to go before it beats the likes of Xaml.  If you are a new MSFT/web-based developer who hasn't had to do deal with Xaml/MSFT tech, I can understand (and envy) your bliss.  However, the veterans here are quite ingrained and satisfied in our approaches and it is this overlooked/neglected fact that is causing the friction in our community right now.
Thank you for your continued dialogue around this matter. :)

That sounds like a really good idea @jasonwilliams200OK, however, this issue has (unfortunately) been labeled as "distant future" and I can see why. Despite this, we could make our own repo, taking you idea. We could make our own compiler and task runner, using a minimal build.json to specify cpus, tasks and what to compile to where (like popular compilers and task-runners). It could also be cross-language, done by grouping the languages in the build.json. This removes the need for a solution and project file.
Here is what I will do: Create a repo called "buildup" and start development of the idea I mentioned above. I will need help with making the compiler.
Happy coding!

Hahah @Gum-Joe trying to make something happen in an open source repo. :) :+1:

Now live at Gum-Joe/buildup

:+1:

To be sure, that's: https://github.com/Gum-Joe/buildup
:) :+1:

Yep :) :+1:

Will begin developing it as soon as possible

One thing: It should be cross-platform ( some platform-specific code) using g++-4.8 and Visual Studio 2015

Please contribute.

I need help

@Gum-Joe, can you please create a gitter channel for your repo buildup, to further this discussion? I have mentioned our discussion on CoreCLR channel: https://gitter.im/dotnet/coreclr. :)
Also slightly related stuff on gyp inspired concepts: https://github.com/aspnet/dnx/issues/3173.
The bonus point is in package.json, we get intellisense for free even in Community Edition of VS2015! The intellisense goes like this:

Type the dependency name and add colon : and open a double-quote, it will populate the latest package version from the npmjs.org.
In binding array under package.js, it parses the available tasks from the same package.json.

Some of these features will come from this VS extension: https://github.com/madskristensen/NpmTaskRunner, which along with https://github.com/madskristensen/WebEssentials2015 are prototype projects (a play ground) for VS vNext features (Mads is the manager of VS web tooling webdev team). There is a lot that can be done by mix and match.
@Michael-DST, regarding POCO mapping, I think WE2015 uses Roslyn to map code layout between C# and TypeScript to provide the features like "right-click C# file in Solution Explorer, hover over Web Essentials and click Generate TypeScript interface". There are other extensions to translate the whole .NET dll to form TS interface typings. The similar approaches can be used to reverse transform and generate POCO / DTOs types in C#.
We can even run csc.exe, vbc.exe and cl.exe or as part of script in pacakge.json before MSBuild even get a chance to step up. :smile:

@jasonwilliams200OK that is great from a new MSFT/web developer/TS perspective, but again it seems to lack any consideration and/or thought from a veteran/MSFT/C#/.NET perspective, hence the described friction/growing frustration from the veteran crowd.  Unless I am misunderstanding you.  What the veteran .NET/MSFT crowd wants is to work in C#/Xaml and build their solutions as such -- NOT TypeScript/JSON.  Additionally, it seems as if you are confirming my suspicions that the package.json file is not made from a serialized .NET POCOs (lower TCO) but is meant to be loaded as a dynamic/schemaless object which is more expensive (higher TCO) to work with, as the schema has to be inferred from a loosely/dynamic-typed mechanism.
Please correct me if I am wrong here and/or if I am completely misunderstanding something.  It wouldn't be the first time this has happened. :)

@jasonwilliams200OK: I have created a gitter chat at https://gitter.im/Gum-Joe/buildup

@Michael-DST, I totally understand the rationale of sticking to MSBuild from veteran C# devs' perspective. I was just highlighting the fact that today with the virtue of MSBuild extensibility, we can work with those facets and offload many build related stuff to this JSON-driven manifest. Ultimately, my hope is MSBuild to provide JSON and YAML schemas to provide parallel support so we can write our build story in the data representation language of our choice. :).

OK great @jasonwilliams200OK.  Thank you for the engaged and thoughtful dialogue.  I am glad you hear the "other" side and I hope we can all land on a great solution that satisfies each side's (or role's/actor's/persona's) requirements.

Thanks everyone for the feedback, discussion, and insights. We’re strongly considering more concise and expressive markup languages for future build engines. For MSBuild itself, the existing tooling ecosystem (Visual Studio and third-party) is too tied down to the existing XML format. We feel that the risks involved with a change in build-specification representation outweigh the benefits.

@rainersigwald thank you for adding and contribuiting to the discussion. :)  I was worried that no one was really paying attention to this, as dialogue has been sparse.  Am I understanding correctly that you will be sticking to the current XML paradigm/system and no modifications will be planned or made around this?

@Michael-DST That's correct.  We're happy to get proposals for (backward-compatible!) changes to project representation, but MSBuild's file format will remain XML (even if we wouldn't choose that if we were starting from scratch today--and I wouldn't!).

@rainersigwald Well that certainly is disappointing.  When you say you've considered the risks, I hope you have considered the risk in the form defections from MSBuild altogether for sticking with a format that is pushing (if not pushed over) a decade in age.  It does seem there is overwhelming demand and feedback for a switch in (or support for other) file format(s) and it is disappointing to say the least that the MSBuild team will not consider this for the foreseeable future.
At the very least this will reflect poorly on the MSBuild product line as the XML format will continue to be difficult to work with and will give it a dated/older, antiquated look and feel.  This makes it difficult to build upon and hampers its competitive appeal.
In addition to this, I guess the concern is that this seems like such a fundamental concern/issue and it is not getting the urgency/priority from the team.  I guess it would help to know what issues you have decided to work on instead to help better understand.
Of course, this is just coming from my (opinionated smile) perspective.  I could be wrong and completely missing the pulse here.  Wouldn't be the first time. :P Thank you for any consideration and continued thoughts towards/around this.

@rainersigwald I guess that is a "yes we considered it and we don't care." :P  Thinking that this should be called MSBuild vSame rather than vNext. :P
I would like to take you up on your proposals fro backward-compatible project representation, however.  You can definitely represent anything in Xaml, and benefit from the built-in tooling available in Visual Studio due to it.  What would be the first step to this?  Would you like me to try to build you a Xaml-fied version of a MSBuild "script" and we can take it from there?  Trying to clarify what you mean by proposal. :)

@Michael-DST It might be helpful to think of this repo as “MSBuild vSafe”—the focus here is on improving the existing MSBuild for its current users, but not making invasive, large-scale changes.
We don’t have anything to announce right now, but you might be interested in some things that have been posted externally.

Haha thank you for your reply @rainersigwald.  It is much appreciated.  I do have to say that the idea of a team of interns building a build system does not inspire the greatest of confidence.  In fact, it is probably this exact approach/methodology/strategy that can be attributed to the reason why MSBuild vSafe is in such the state it is now. :P  It also sounds like there is talk about inventing a whole new language, and even referencing TypeScript, which is completely incompatible with .NET.  Internal MSFT teams do know about .NET, right?  It is hard to tell sometimes as it seems like there is always at least one team trying to skate uphill and create something completely new, different, and completely incompatible with all of the work, effort, and knowledge invested in, well, what currently works.
Btw, what I am proposing (using your words/suggestion here) is not a large-scale/invasive change, but a way that improves the current development process which I think we all can agree can stand some (read: a lot of) improvement.    Every respectable developer I know cringes at the thought of opening a .csproj file and wading through the mire of a schema-less, arbitrary elements that ultimately (if you're lucky) bind to obscure .NET counterparts somewhere that are nearly impossible to track down.
It would seem to me that if you are going to focus on improving the existing MSBuild for current users, that this area might be an area to consider in which to do exactly that.  With all of this said it does seem like I should bite my tongue until April before I pass any judgement (too late, I know haha).

This is more relevant than ever! ASP.NET Core project.json is going away and is instead planned to use msbuild. So why not bring the storm here, and demand JSON support for msbuild?

@Ciantic you mean JSON or Xaml. :wink: :wink: :wink:

Given the new climate around project.json and MSBuild, I've created a new issue around this to further the conversation in a new light: https://github.com/Microsoft/msbuild/issues/613

@Mike-EEE

What the veteran .NET/MSFT crowd wants is to work in .NET/C#/Xaml and build their solutions as such -- NOT TypeScript/JSON

Um wow. Well I don't want to build my solutions with Xaml actually. I like doing front ends in TypeScript/Angular, and I don't like WPF.
Wow, so I must not be a veteran developer.
My 21 years working development experience on the MS stack, developing COM, ATL, MFC, Win32, .NET from 1.0 beta onwards, experience writing thick client products, thin client apps, monster admin portals, websites. Writing Reactive Extensions systems, highly concurrent systems, trading engines, high performance trade costing systems, all that, and I'm still not a veteran.
All I need to do is say that I prefer Xaml to JSON and then I'm a veteran developer.
Because veteran .NET developers only use One True Way™, they don't pick and choose the best that they've found from a wide and deep experience. They only use C# and Xaml.
Sorry, but that's the same basic argument as the rest of the people on this thread who appear to believe that if you don't like MSBuild it's just because you don't understand it, and it can't be that you used it for years, and rejected it.

PS. I would rather use a non-MSBuild based Xaml build system than a MSBuild based JSON build system.


feat: add graphql cli

Addresses: #37
Signed-off-by: Ramakrishna Pattnaik<EMAIL_ADDRESS>

To generate the entity model, two libraries were explored: graphql-cli and graphql-code-generator.
It was decided to go with graphql-cli as it offered more options over graphql-code-generator.
The various ways to load schema have been discussed below:

Load from a URL http://localhost:3000/graphql
Load from a local file src/**/*.graphql

These approaches would have been fine for development bit could cause inconsistencies in case strimzi-admin schema gets changed/modified.

Git sub-modules

Managing github modules can be cumbersome.

Using github loader and pointing to a tag with the desired schema.

Github loader is able to download schema associated with the tag but it needs a Github personal access token which has to be passed as an environment variable.
Furthermore it seems unnecessary to use token to get files from public repo.

Providing the URL to raw schema file https://raw.githubusercontent.com/rkpattnaik780/enmasse/14c4e82a0c13370d5e14a74669982e1a1105a0ba/console/console-init/ui/mock-console-server/schema.graphql

This gets the work done for now, it requires to pass the commit ID of the tag. However we might need to fallback to a traditional method as pointing to a different github repo does not count as best practice.

Amazing work. From my side to move this next step further it will be good to bring the actual graphql endpoint and see if we can generate hooks.

Yes. Schema first development in the glance. Codegen generates types - Makes server side resolvers fully typed and CLient side types and even data layer. Practically sealing entire API contract.
The best pattern for working is to snapshot server-side schema in the repo to not get exposed by "Friday Evening PR merge" problems etc. - Getting schema updates from the server when requested/released rather than using github master

This schema can then be used/referenced in our MockApi too (in effect completing #50 )

GraphQL CLI can create mock out of the box.

Sorry for the delay in following up @rkpattnaik780 / @wtrocki - thanks for answering my first set of questions.
As is today, we have code which will introspect the backend to figure out what the schema contains (at runtime). We also will have code which will discover what the user has authorization to do. As described in the docs, the intent of the entity model was to combine these two inputs into a 'yes'/'no' CRUD abstraction (+use case specific items, such as live updates (subscriptions) etc).
What I am missing here (and please correct me/let me know the intent) is how a generated version of the schema will help provide this model. We introspect the server already, so we know what is there. We (will have) information about what the user can do - how were you seeing these pieces come together?

As is today, we have code which will introspect the backend to figure out what the schema contains

Sounds complex but I think I understand what intention is.

What I am missing here (and please correct me/let me know the intent) is how a generated version of the schema will help provide this model.

Little bit confused. We do not generate schema - more like typings (if we would want we can generate client side queries but this will be overkill for such simple schema)
In my mind generation is not runtime artifact, but development artifact and it is not affecting any runtime architecture mentioned above. Feel free to ping me on slack to clarify.

We introspect the server already, so we know what is there. We (will have) information about what the user can do - how were you seeing these pieces come together?

I had some chat with folks about where schema should land etc. Introspecting server has multiple drawbacks of snapshoting schema (which is being used very often - especially with schemas that have more than >100 types.

@wtrocki @matthew-chirgwin  - my reading of this PR is that it's creating TS types from a graphql schema for development purposes. So that we can nicely handle gql results in TS.
While this is useful from a development perspective, I believe the intent of the entity model is instead a way to model the available capabilities in the system, based off the result of a graphql introspection.
E.g - introspect shows there is a topics query - and user introspection shows the user can create topics. As a result - the entity model (which is passed around the UI) must be built at runtime to state that we can render a "create topic" page.

I'm not sure how you can create types at runtime in a strongly typed language.

my reading of this PR is that it's creating TS types from a graphql schema for development purposes. So that we can nicely handle gql results in TS.

It might be more. It creates an entire data access layer using client requirements specification (queries, mutations). It means that there is no need to deal with graphql in the code at all and the code is actually detached.

While this is useful from a development perspective, I believe the intent of the entity model is instead a way to model the available capabilities in the system, based off the result of a graphql introspection.

I understand what we are saying, but it is not clear what requirement pushed us to have that architecture and also do not see why one excludes another. From my experience it looks like we are using introspection for what it wasn't really designed for, but still if there is reason to do so.. why not.. I do not want to change the discussion from: "do we need codegen" to "is this architecture valid" because I'm not officially involved in the project (I can be) but in my understanding there is no real blocker for having this PR merged.
I'm happy to discuss patterns. I have been representing Red Hat in the GraphQL Foundation Group so if we want to add something to the GraphQL or extend it to handle some use cases where you feel that we need to hack around GraphQL etc. we can make things happen (or build some upstream toolign around it).
We could have short video call.

Major preface: I do not want to stifle the discussion, or options required to provide the entity model in any way. If this is part of an approach to achieve what is requested in #37 then I am all for understanding/discussing it.
It sounds to me like there are some very crossed wires here. From your description @wtrocki it appears that this tooling will in effect replace/supersede our usage of Apollo in the client side by generating code to interact/access the backend based on a referenced schema.
The reason we went with introspection at runtime is we want to use the available schema as a mechanism (in combination with other sources of data) to enable and disable features. That is the intent of #37 - a model to combine results from introspection, authorisation etc, to provide a simple Yes/No answer to if a type, field or operation are possible for the UI to use were needed.  Eg, if no ‘Topic’ type exists on the backend, we should not show any topic pages/data/UI etc.
I am curious as well, can this code generation approach deal with things like schema federation? Again, a reason we went with a runtime check here is to allow flexibility. Strimzi-admin today will host a GQL api which will service just topic information - but this could be (optionally) extended in due course, and I expect modules (say for metrics) would be federated into the overall schema if there was ‘metrics’ enabled/deployed as a part of a Strimzi deployment.

My understanding of this issue is to generate an entity model. This is essentially a set of typescript types/interfaces that represent the schema. This cannot be generated at runtime, we have to code against it. This is somewhat orthogonal to introspection which is to determine if the capability exists at runtime.
Or were you thinking to go with a detyped entity model?
I would avoid schema federation unless it's critical for the functional requirements. It is complex, causes some things to not work well, and will slow the UI down.

While this is useful from a development perspective, I believe the intent of the entity model is instead a way to model the available capabilities in the system, based off the result of a graphql introspection.

The introspection is already done. This should be combined with the entity model to determine what can be rendered.

E.g - introspect shows there is a topics query - and user introspection shows the user can create topics. As a result - the entity model (which is passed around the UI) must be built at runtime to state that we can render a "create topic" page.

My understanding of this issue is to generate an entity model. This is essentially a set of typescript types/interfaces that represent the schema. This cannot be generated at runtime, we have to code against it. This is somewhat orthogonal to introspection which is to determine if the capability exists at runtime.

Agreed. For sake of the discussion/clarity, the original ask of the issue is to write a piece of code (at develop time), called at runtime which in effect reduces the result of introspection, authorization etc to an entity (and operations on that entity) centric view for the UI to make use of. Using the example of the topics page, if the introspection result shows no mutation to create, no 'create topic' button would be shown. Similarly, if the mutation was there, but the user doesnt have the authoization to create topics, again, the button would not be shown.
Having said that, there are of course other ways of achieving the same effect. What I fail to see here is how what this PR contains is/would be used to achieve the outcome of this issue.

The reason we went with introspection at runtime is we want to use the available schema as a mechanism (in combination with other sources of data) to enable and disable features.

There are much better  (and simpler mechanisms to achieve that with GraphQL).
Using introspection for this purpose has so many drawbacks that I might hit the limit of github comments.
Generally, Strimzi UI is an open source project so the simpler architecture it has the more contributors will attract in the future. We can look into something lean, but as GraphQL.js contributor and generally working with GraphQL for last 3 years I could definitely recommend to see if we and start snapshotting schema (introspection can still be used) so this is not a big architecture change. However feature enablement might be done better with metadata (https://github.com/aerogear/graphql-metadata)/Directives/GraphQL extensions fields/Meta tags.. introspection advisably would be development artifact for me rather than something to use in production. Happy to discuss. I see a couple of challenges in current architecture for scalability as well.
Generally, the more we diverge from how graphql is normally being used in the big players and move from standards the less possibilities we will have in the future to mitigate problems like performance etc.
For example: https://www.apollographql.com/docs/apollo-server/performance/apq/

Strimzi-admin today will host a GQL api which will service just topic information - but this could be (optionally) extended in due course, and I expect modules (say for metrics) would be federated into the overall schema if there was ‘metrics’ enabled/deployed as a part of a Strimzi deployment.

Ok. Then it would be good to put some public proposal for this and look for possible options.

I am curious as well, can this code generation approach deal with things like schema federation? Again, a reason we went with a runtime check here is to allow flexibility. Strimzi-admin today will host a GQL api which will service just topic information - but this could be (optionally) extended in due course, and I expect modules (say for metrics) would be federated into the overall schema if there was ‘metrics’ enabled/deployed as a part of a Strimzi deployment.

I am curious as well, can this code generation approach deal with things like schema federation?

Schema federation is completely different topic here. Based on my understanding Node.js gateway needs to be more router than federation as all servers schema will be the same (with some subsets of features/enablement etc.)
In Red Hat we have our own high-performance GraphQL Federation solution:
https://github.com/chirino/graphql-gw
We also had deployed GraphQL Federation etc.

+100 to what @pmuir was saying. To be clear I'm here as a community member not as Red Hatter.
Since this is a public repository in high profile project it would be better to bring this to more top level discussion somewhere on proposal/issue where we could discuss with the context of the change.
I would like to be able to point out my colleague who written introspection standard for GraphQL to some thread without much noise etc. so he can give us independent view (my take can be blurred as I have been writing things certain way and build some librariries that archieve features that have you mentioned. Let's work on this in the open standard way like the other Strimzi projects.
Once we get clarification on the path we can really make Strimzi UI successful and popular open source project.

I've re-read the original description of this - https://github.com/strimzi/strimzi-ui/blob/master/docs/Architecture.md#entity-model - and I think some of confusion may be that what the architecture calls a "entity model" is typically called a data access layer (e.g. https://en.wikipedia.org/wiki/Data_access_object) or a repository, whilst typically the "entity model" refers to entities and their relationships (e.g. https://en.wikipedia.org/wiki/Entity–relationship_model).

Leaving to one side the debate about whether the data access is cocrrect.
How are we specifying the entities (e.g. Topic) and their fields (e.g. partitions)? These types need to be available at development time.

Given the discussion in the PR and the original intent, I believe the next steps are as follows:

We use the tooling in this PR to generate a set of files containing all the possible types/fields from the strimzi-admin schema

Follow on question: as these are used in the client, should the go into a folder in the client directory (as they also need to be checked in)

The existing documentation is updated (as a part of this PR) to mention this occurs, and that said generated code is used in a ‘reducer like’ process with other data (the results of introspection, authentication, authorisation etc) to output a view the rest of the UI can use to enable/disable features based on what is available at run time
Change/rename ‘Entity model’ to something more explicit to this process (to avoid future confusion).


MozFest Session - Youth, LGBTQ and You

Preparing the 1-hour session at MozFest.
It is going to be on Sat afternoon.

[ ] Check with social worker on the number of people coming
[ ] Getting documents from Mozilla
[ ] Tickets for YP, faciliators and social worker
[ ] Working template design
[ ] Send print files to Andrew (Mozila) one week before deadline
[ ] Session planning
[ ] Session deck
[ ] Time box
[ ] Brief students from UAL


keywords whitespace is not included in syntax checker

as you can see, it seems like rec is being counted as keyword, nix parse this correctly, but this ext does not
I assume its a problem in /syntaxes/nix.YAML-tmLanguage sections of line 607 or 114
or,
a general case for all keywords, I'm not used to its syntax

@jnoortheen

The syntax is copied from https://github.com/wmertens/sublime-nix project. Contributions are welcome to improve it.


Pop to root view

Allows a user to pop all the way down the root view, similar to UINavigationController.popToRootViewController

@programmarchy Thanks for the PR — would you mind merging master (I fixed an issue that was causing tests to not run) and then add a few tests?

Ok, ready to merge. Once merged, I'll write a lifecycle test for __popToRootView, too.

Thanks! I'll publish 2.1.0 after you submit that PR.


Translation into Japanese

Hi, I'm Sho from Japan.
Would you mind if I translate this repo into Japanese?

I also would like to submit Korean localization work gladly with Japanese localization.
I also have Korean version of this awesome lab.
(Please check this out)
Thank you for opening the gate, @sh-tatsuno

I've updated the copyright on the repo and have chosen to adopt a creative commons license which grants you permission to do the translation and as long as you agree to share to content under a similar license and not for commercial usage with prior approval.

@sh-tatsuno
Hey, actually I have just finished the translation into Japanese.
https://github.com/inductor/kubernetes-the-hard-way


updating Storm version in Pulsar

Motivation
Currently pulsar-storm connectors are using Storm 0.9.5, which is a very old version of Storm.  Updating the Storm dependency to 1.0.5.
Modifications
Changed all backtype.storm -> org.apache.storm
Deleted checking for tick tuples in the Pulsar Bolt.  Its not needed

@revans2 can you take a look as well and confirm about the tick tuple?

@merlimat,
@jerrypeng is right that tick tuples are generally configured on a per component basis.  It is possible for someone to set it for the entire topology, but most components will not know how to handle it and will likely end up with exceptions.
If you are scared about breaking compatibility, because a user could set it before without issues, it should not be that big of a deal to leave the tick tuple checks in place.  But if you do org.apache.storm.utils.TupleUtils.isTickTuple is the new preferred way to do it.  It will be a very small performance cost if you do leave it in place though.

@merlimat backed by popular demand I have added back the tick tuple check

Thanks @jerrypeng  & @revans2


docs: document global variables in MDX scope

Motivation
Complete #5200 because that can't be merged without CLA and doesn't look like the author is ever responding.
Have you read the Contributing Guidelines on pull requests?
Yes

I didn't document the __filename variable because when we migrate to ESM it may be lost (didn't investigate), and when I tested it points to index.js with no other information, and I think because this is ultimately client-side it's not going to be hugely useful.
assets and metadata are not documented either because they may be changed in the future. The other variables are more useful for the client-side user.

Thanks, makes sense
Not even sure we should document contentTitle though, any use-case in mind to want to use it?

Not even sure we should document contentTitle though, any use-case in mind to want to use it?

No, but it's just such a simple API and I don't expect it to change in the future😄 And it's less than useless compared to __filename


Add onThisPageNav flag to the ThemeSettings.spec.json

Bug/issue #, if applicable: 101345143
Summary
The OnThisPageNav changes to be optional. This PR documents the change in the spec.
Dependencies
NA
Testing
NA
Checklist
Make sure you check off the following items. If they cannot be completed, provide a reason.

[ ] Added tests
[ ] Ran the ./bin/test script and it succeeded
[ ] Updated documentation if necessary

@swift-ci test


[SDL-0189] Scripts for Restructuring OnResetTimeout feature

ATF Test Scripts to check #SDL-0189 Restructuring OnResetTimeout
This PR is ready for review.
Summary
Commits 7de343968859cda66fad694cdc5e1bc358888139 and 1568d15d1362c9284ca01d0d1c369ddbb519cbf3 are reviewed by Ford
Added not functional update in f2d1e080e5d0874cefc27c9c806f073b86fd54bb
Added the precondition with successful SetInteriorVD for checking RPC with consent
ATF version
develop
CLA

[x] I have signed the CLA

@dboltovskyi, please review


Add subscribe to channel link to shows pages

Not sure where to add, but would like to see on all pages under /shows
Subscribe

We have a bug to redirect people to twitter and I've added G+ and YT into that, so would rather encourage people to the YT channel that way and for shows encourage people to subscribe to the RSS feeds for shows or drop the shows feeds and only encourage subscription of YT.
What do you think?
OR do we drop shows now that web shows are separate?

@PaulKinlan for thoughts on this

I would like to see the feed present and discoverable via feed readers, but
if we have any UI on the page I would much prefer to get people to sub to
YT as quickly as possible.
On Fri, 18 Sep 2015 at 16:27 Matthew Gaunt<EMAIL_ADDRESS>wrote:

@PaulKinlan https://github.com/PaulKinlan for thoughts on this
—
Reply to this email directly or view it on GitHub
https://github.com/google/WebFundamentals/issues/1734#issuecomment-141482784
.

cc @PaulKinlan @petele
I'm just thinking that Shows is a struggle to maintain and the only major advantages was to separate web shows and offer a feed.
If we are driving people to YT subscribe - let's just do that.
We can build something that generates a feed using the Youtube API if needs be.

We have that tool already.
I really want /web/shows to exist because it increases the surface area for
discovery and extra content.
On Fri, 18 Sep 2015 at 16:43 Matthew Gaunt<EMAIL_ADDRESS>wrote:

cc @PaulKinlan https://github.com/PaulKinlan @petele
https://github.com/petele
I'm just thinking that Shows is a struggle to maintain and the only major
advantages was to separate web shows and offer a feed.
If we are driving people to YT subscribe - let's just do that.
We can build something that generates a feed using the Youtube API if
needs be.
—
Reply to this email directly or view it on GitHub
https://github.com/google/WebFundamentals/issues/1734#issuecomment-141486277
.

Discussion points with @petele:

Integrate auto generation into shows (i.e. there are no markdown files).

Would need to move written content into something else (i.e. medium) and then link from YT description to medium post.

Rather than a page for every show have a page with a single embed for the season playlist

Thoughts?

I've just built a generator in node that has a interface on the command line to make it easier to add files.
I'll add in the subscribe button into the layout tomorrow.

@PaulKinlan @petele thoughts on this?

Can we make it a little tighter? All on one line.

Suggested code:
{% if page.feedUrl %}
{% assign colwidth="mdl-cell mdl-cell--4-col" %}
{% else %}
{% assign colwidth="mdl-cell mdl-cell--6-col" %}
{% endif %}

Keep Up to Date

        {% include svgs/youtube.svg %}

      Subscribe to Our Channel

        {% include svgs/rss-icon.svg %}

      Follow our Shows Feed

  {% if page.feedUrl %}

        {% include svgs/rss-icon.svg %}

      Follow the {{page.feedName}} Feed

  {% endif %}

Subcribe | Shows |

I'm OK with that, you ok with the code or want to do do something different?


Update react-dropzone to newer version

Right now react-dropzone is pinned at a very old 5.1.0 version, while the latest is 11.something. It wouldn't be a problem in itself, except that the API is very different and Volto developers need to be aware of this fact, to research older documentation.

@tiberiuichim good point. @iFlameing maybe you can look into this next week.

@tisto react-dropzone has breaking changes we have to refactor all the dropzone component to newer API. What do you want me to do?


Add unit tests in GH Actions

This PR adds support for running unit tests in Pull Request pipelines.

@andrasbacsai Can you approve this workflow? I've tested it first here: https://github.com/Thijmen/github-actions-testing/pull/1
I am keen on understanding if this works for this repo.

Let me dig into this as to why this is not working. I'll ping you once I think it's fixed.

@andrasbacsai I made a small mistake by copying it from my repo, I've updated the action now to execute the proper docker-compose service.

@andrasbacsai Can you approve the workflow, so we can see if it works?

It's ready for another swing @andrasbacsai :)

@andrasbacsai Can you run the tests, so we know if it works?

I will close this PR for inactivity.


Release engineering improvements and cleanups, auto tags

ref: #960
Made some tests on auto tag pushing here: https://github.com/sbcgua/ci-abap-versioning-test
I propose to integrate it into AG
The ideas is: if zif_abapgit_version=>gc_abap_version changes - publish a new tag
Along with this I'd propose a couple of cleanups for the current ci scripts:

move ci scripts (name travis.sh and the new tag deployer) to ci dir
adjust package.json

remove pretest
test = npm run eslint && npm run lint
remove posttest, instead move to merge script (abapmerge ...) - it is not a test step
remove _disabled_posttest (or it's used ? then rename it to lint-merged)

consequently tune the travis script

re-use npm run merge

optionally replace GITHUB_API_KEY with deployment_key - which is an SSH key to the specific repo (build). Well, just a suggestion, GITHUB_API_KEY give access to the whole account so kind of less secure.

when github actions goes into GA(november?) I'd probably like to move to that instead of travis
guess the key is required anyhow for pushing to https://github.com/abapGit/build ?

I agree with GA, but I'd separate this step to reduce complexity. Actually I'll try to dive into GA too.
Key: this is up to you :) Have a look at the repo I mentioned above - it uses the ssh deploy key. So you can add a new key to build repo and use it in another environment e.g. this one. But anyway it is optional, let's keep it as a separate step and only if you prefer.

🎉

anything else needed to close this issue?

imho let's close
migration to GA can be a separate one
And I'd wait for the release ... after some hands on with GA I just got convinced in feeling that it is quite beta ...

agree and agree


Detect some popular SSGs and automatically adjust default path(s) accordingly

Expands on #1.
Could pull some of the logic from https://github.com/netlify/cli/tree/master/src/detectors

I personally think it might be best to keep this plugin generic.
When it comes to library/third-party/SSG specific cache, Netlify already tries to perform this, regardless of Build plugins, as part of the build-image. For example here. It would be more useful to send PRs to the build-image to add more logic there than to augment this plugin IMHO.
However, caching logic that target only one library/third-party/SSG are perfect candidates for Build plugins! I think mixing it with the generic approach of this plugin might decrease its simplicity.

Completely agree, the simpler the better. Good to know how much the build image already does. Between that and the existing more specific plugins I'll keep this generic as advertised. 👍