Thinking Like an IDE

Server-side Swift is an amazing new technology that aims to reduce the gap between application and server-side developers. How are tools adopting this new technology? How should they transform and rethink their integrations to help server-side developers? Which challenges do they have with the growing amount of new frameworks and the evolution of project models? Which possible steps should developers consider when maintaining their frameworks to integrate them into existing IDEs easier? How language developers can help IDE creators? All these questions will be answered.

Let’s try thinking like an IDE and take a look at all the challenges that server-side Swift brings to IDE and tool creators. Let’s talk about the most important issues when adopting a new technology and understand how framework developer teams working on the Swift language and IDE developers, can help each other.

Transcript

1. Server-Side Swift: Thinking Like an IDE Stanislav Dombrovsky JetBrains @s_dombrovsky
2. • Xcode • AppCode and CLion • VSCode - Maintained Swift Development Environment (SDE) • Atom - ide-swift, nuclide • Sourcery, Refactorator, SourceKitten Tools —
3. • Project Model → Swift Package Manager (SPM) • Code Engine → SourceKit or our own engine • Build, Run, Debug, Test → SPM + LLDB • macOS and Linux • Integrations What do we need? —
4. The Project Model — Project ├─ .build │ └─ checkouts ├─ Sources │ └─ Project │ └─ main.swift ├─ Tests │ └─ ProjectTests │ └─ Tests.swift └─ Package.swift
5. • VSCode, Atom: folder • CLion: project • No code assitance for Package.swift: • Code Engine first? • Or Project Model? The Project Model - current state —
6. The Code - SourceKit — • macOS and Linux • key-value protocol • Service / Client
7. The Code - features — • Highighting (open) • Documentation (docinfo) • Completion (codecomplete) • Warnings, errors, fixits • Navigation (open.interface) • Formatting (formattext) • And more
8. The Code - current state — • Atom (ide-swift, nuclide): • Completion and highlighting • VSCode (SDE): • Completion and highlighting, documentation, error reporting • CLion and AppCode: • Code assistance - own engine • Warnings, errors (SourceKit + own engine) • Xcode: SourceKit
9. • Dependencies (Atom, VSCode) • PackageDescription for Package.swift • SourceKit performance The Code - problems —
10. • key.compilerargs! • Solution: • swift build • .build/debug.yaml • Parse and cache (nuclide) • Module name + .build/debug The Code - dependencies —
11. • Slow, high CPU • Solution: • Service (SDE) • Handle errors • Always have one process (ide-swift, nuclide) The Code - performance —
12. • Standard libraries • Too many SourceKit requests (slow) • Indexing/cache system (Sourcery, Refactorator) • Xcode: • LMDB via private SourceKit.framework • Requests for global/local refactorings • Objective-C/C/C++ support • SPM? No. The Code - code generation, refactorings, navigation —
13. • Easy to integrate • VSCode: • watches, breakpoints, UI • Atom: • command-line • AppCode, CLion, Xcode: • everything integrated Build, Run and Debug source code —
14. • Atom, CLion: Run only • VSCode: Run/Debug • Xcode, AppCode: • Run/Debug • have test UI • not for SPM projects • Generated test names? • To be improved Build, Run and Debug tests —
15. • Open Source cache system • More SourceKit requests • Not only language • No swift build for UI • Workgroup? How can language developers help tool creators? —
16. • SDE: • Completion for dependencies • Unit tests • ide-swift: suggested the same • nuclide: patch for completion • Refactorator: shared information about LMDB Some action points —
17. Server-side Swift. Integrations - what do we need? — • Language support • Run, Debug • Menus and actions • User Interface
18. Server-side Swift. Languages - what do we need? — • HTML, CSS, JavaScript, TypeScript • At the same level as Swift/Objective-C • React, Bootstrap, others • Run and Debug
19. Server-side Swift. Languages - current state — • Atom, VSCode: built-in support • CLion, AppCode: bundled plugin • Xcode - RegExp-based highlighting and completion
20. • Injected language • Difficult to implement Server-side Swift. Web templates —
21. • Support existing ones • TextMate grammar: • highlighting • completion (snippets) • Plugins Server-side Swift. Web templates - what to do? —
22. • AppCode, CLion: • Handlebars/Mustache, Markdown • Stencil (only template syntax via TextMate bundles) • VSCode, Atom: • Handlebars/Mustache • Markdown • Stencil • Leaf Server-side Swift. Web templates - current state —
23. Server-side Swift. Databases — • SQLite? • • Oracle DB • MySQL • PostgreSQL • MSSQL • And more
24. Server-side Swift. Deployment - Docker — • AppCode, CLion: • bundled plugin • VSCode: • vscode-docker • Atom: • atom-docker • several plugins
25. Server-side Swift. Deployment - SSH/FTP, clouds — • Atom: • nuclide • VSCode: • sftp • AppCode, CLion: • bundled plugin • Clouds
26. • VSCode: • vscode-restclient • Atom: • rester (code) • rest-client (UI) • AppCode, CLion: • bundled plugin Server-side Swift. Request testing —
27. • More frameworks • Separate applications: • Distraction • Too many • Same stack? • Not possible to integrate all of them by yourself Server-side Swift. Plugin infrastructure —
28. • Open API • Private API: • share with those who are interested • help them Server-side Swift. Plugin infrastructure - what to do? —
29. https://yeswolf.github.io/ide/